Block chain-based account splitting and settlement method

Abstract

The present invention relates to the technical field of information. Disclosed in the present invention is a block chain-based account splitting and settlement method, comprising: acquiring an account splitting and settlement request belonging to a current time period; invoking a first smart contract to perform risk and compliance review on each pending transaction in a pending settlement form, and adjusting and optimizing the pending settlement form on the basis of a risk and compliance review result to obtain an optimized pending settlement form; invoking a second smart contract to perform account splitting and settlement on the optimized pending settlement form, and recording account splitting and settlement data generated during account splitting and settlement; and when the account splitting and settlement is completed, encrypting and storing the optimized pending settlement form and the account splitting and settlement data into a block chain, and repeating the above process to execute an account splitting and settlement request of a next time period. The present invention helps to accelerate capital turnover, reduce capital retention time, and improve account splitting processing efficiency.

Description

A blockchain-based revenue sharing and settlement method Technical Field

[0001] This invention relates to the field of information technology, and more specifically, to a blockchain-based revenue sharing and settlement method. Background Technology

[0002] With the increasing complexity of multi-party collaborative transaction scenarios and the continuous growth of transaction volume, the efficiency, transparency, and security of settlement have become core issues of concern to all parties. Traditional settlement methods often face challenges when dealing with dynamic and complex transactions due to cumbersome processes, rigid rules, and insufficient risk control. The lag in fund transfer and lack of transparency in the settlement process not only weakens transaction efficiency but also, to some extent, raises trust issues among the participants. Technical issues

[0003] While some existing improvement methods have partially solved the efficiency problems of fund custody and allocation, there are still shortcomings in compliance and risk control, dynamic rule adaptation, and transparency and traceability of settlement results. The lack of dynamic auditing and real-time optimization capabilities for transaction data makes it impossible to effectively handle non-compliant transactions, potential risks, and complex needs in special scenarios. At the same time, the lack of complete and tamper-proof records in the settlement process makes subsequent traceability and verification difficult, increasing the complexity of dispute resolution. Technical solutions

[0004] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a blockchain-based revenue sharing and settlement method.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] A blockchain-based revenue sharing and settlement method, wherein the blockchain includes a pre-deployed first smart contract and a second smart contract, the method being applied to a revenue sharing server, the method comprising:

[0007] Obtain the revenue sharing and settlement request within the current time period. The revenue sharing and settlement request contains a settlement form consisting of multiple transactions to be settled. These multiple transactions to be processed come from different merchant nodes in the blockchain.

[0008] The first smart contract is invoked to perform risk and compliance audits on each pending transaction in the settlement form, and the settlement form is adjusted and optimized based on the risk and compliance audit results to obtain the optimized settlement form.

[0009] The second smart contract is invoked to perform revenue sharing and settlement on the optimized pending settlement form, and the revenue sharing and settlement data generated during the settlement process is recorded.

[0010] After the settlement is completed, the optimized settlement form and settlement data are encrypted and stored in the blockchain, and the above process is repeated to execute the settlement request for the next time period.

[0011] Furthermore, each pending transaction must contain at least the buyer ID, merchant node ID, product type, payment method, transaction amount, and transaction time.

[0012] Furthermore, the risk and compliance audit results include one of the following: non-compliance, compliance but with risks, and compliance with no risks.

[0013] Specifically, each pending transaction in the settlement form undergoes risk and compliance review, and the settlement form is adjusted and optimized based on the results of the risk and compliance review, including:

[0014] a1: Get the i-th pending transaction in the settlement form, where the settlement form contains M pending transactions, and i and M are integers greater than zero;

[0015] a2: Retrieve the compliance review conditions agreed upon in the first smart contract, and determine whether the i-th pending transaction is compliant based on the compliance review conditions. If it is not compliant, take the non-compliance as the risk and compliance review result of the i-th pending transaction, remove the i-th pending transaction from the original form to be settled, and set i=i+1, return to step a1. If it is compliant, jump to step a3.

[0016] The compliance review conditions include, but are not limited to, restricted product types and restricted payment methods;

[0017] a3: Retrieve the risk assessment conditions pre-agreed in the first smart contract, and determine whether the i-th pending transaction has any risk based on the risk assessment conditions. If there is a risk, mark the i-th pending transaction as compliant but with risk, and use compliant but with risk as the risk and compliance assessment result of the i-th pending transaction. Remove the i-th pending transaction from the original form to be settled, and set i=i+1, then return to step a1; if there is no risk, mark the i-th pending transaction as compliant and without risk, and use compliant and without risk as the risk and compliance assessment result of the i-th pending transaction, and set i=i+1, then return to step a1.

[0018] Specifically, the risk assessment criteria are risk level scoring thresholds;

[0019] a4: Repeat steps a1 to a3 until i=M, then end the loop, complete the adjustment and optimization of the form to be settled, and obtain the optimized form to be settled.

[0020] Furthermore, determining whether the i-th pending transaction is compliant includes:

[0021] Get the merchant node ID in the i-th pending transaction;

[0022] Based on the mapping relationship between merchant node ID and compliance review conditions, obtain the corresponding compliance review conditions for the corresponding merchant node ID;

[0023] The corresponding compliance review conditions are compared with the information of the i-th pending transaction. If the information of the corresponding compliance review conditions is completely consistent with that of the i-th pending transaction, the i-th pending transaction is judged to be compliant; if the information of the corresponding compliance review conditions is not completely consistent with that of the i-th pending transaction, the i-th pending transaction is judged to be non-compliant.

[0024] Furthermore, determining whether the i-th pending transaction carries risk includes:

[0025] Get the merchant node ID, transaction amount, and transaction time of the i-th pending transaction;

[0026] Based on the mapping relationship between merchant node IDs and risk analysis data, extract the corresponding risk analysis data for each merchant node ID;

[0027] The risk analysis data includes the average transaction amount, standard deviation of transaction amount, average transaction time, and standard deviation of transaction time for each corresponding merchant node ID.

[0028] Input the transaction amount, the average transaction amount, and the standard deviation of the transaction amount into the predefined amount risk scoring function. In the process, the amount risk score of the i-th pending transaction is obtained;

[0029] Among them, the predefined monetary risk scoring function The expression is as follows:

[0030] ;

[0031] In the formula: Let i be the transaction amount in the i-th pending transaction; This represents the average transaction amount belonging to the corresponding merchant node ID. This represents the standard deviation of the transaction amount belonging to the corresponding merchant node ID;

[0032] Input the trading time, the average trading time, and the standard deviation of the trading time into a predefined time risk scoring function. In the process, the time risk score of the i-th pending transaction is obtained;

[0033] Wherein, the predefined time risk scoring function The expression is as follows:

[0034] ;

[0035] In the formula: Let i be the transaction time of the i-th pending transaction; This represents the average transaction time for the corresponding merchant node ID. This represents the standard deviation of the transaction time belonging to the corresponding merchant node ID;

[0036] Calculate the risk level score of the i-th pending transaction based on the amount risk score and the time risk score;

[0037] The formula for calculating the risk level score is as follows:

[0038] ;

[0039] In the formula: Score the risk level of the i-th pending transaction. and For a risk weight greater than 1, ;

[0040] The risk level score is compared with the risk level score threshold in the risk review conditions. If the risk level score is greater than or equal to the risk level score threshold, the i-th pending transaction is determined to have risk; if the risk level score is less than the risk level score threshold, the i-th pending transaction is determined to have no risk.

[0041] Furthermore, the step of performing separate settlement on the optimized pending settlement form includes:

[0042] b1: Obtain the j-th pending transaction from the optimized settlement form, wherein the optimized settlement form contains N pending transactions, j and N are integers greater than zero, and N≤M;

[0043] b2: Obtain the merchant node ID in the j-th pending transaction, and retrieve the corresponding revenue sharing rule in the second smart contract based on the mapping relationship between the merchant node ID and the revenue sharing rule; the revenue sharing rule includes at least the revenue sharing amount ratio and the revenue sharing participant nodes;

[0044] The revenue-sharing participants include merchant nodes, e-commerce platform nodes, and bank nodes.

[0045] b3: Calculate the multiple distribution amounts of the j-th pending transaction according to the corresponding distribution rules, and allocate the transaction amount of the j-th pending transaction to the private wallet address of each distribution participant node according to the distribution amount, and let j=j+1, then return to step b1.

[0046] b4: Repeat steps b1 to b3 above until j=N, then end the loop and complete the settlement of the optimized settlement form.

[0047] Furthermore, the settlement data includes at least multiple pending transactions that have completed settlement, multiple settlement amounts that have been completed, the corresponding settlement participant node for each settlement amount, and the private wallet address of each settlement participant node.

[0048] Furthermore, the step of encrypting and storing the optimized settlement form and revenue sharing data in the blockchain includes:

[0049] The pending settlement form and the split settlement data are merged to generate the split settlement result data;

[0050] The settlement results data are segmented to obtain multiple data segments.

[0051] Each data shard is merged in a staggered manner to obtain multiple merged shards;

[0052] Each merged shard is hashed to form multiple blocks and a hash index for each block, and each block is stored on the blockchain according to the hash index.

[0053] A revenue-sharing server includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the blockchain-based revenue-sharing settlement method described above.

[0054] A computer-readable storage medium storing a computer program that, when executed, implements the blockchain-based revenue sharing and settlement method described above. Beneficial effects

[0055] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0056] This application discloses a blockchain-based revenue sharing and settlement method, comprising: obtaining revenue sharing and settlement requests within the current time period; invoking a first smart contract to perform risk and compliance audits on each pending transaction in the revenue sharing and settlement form, and adjusting and optimizing the revenue sharing and settlement form based on the risk and compliance audit results to obtain an optimized revenue sharing and settlement form; invoking a second smart contract to perform revenue sharing and settlement on the optimized revenue sharing and settlement form, and recording the revenue sharing and settlement data generated during the revenue sharing and settlement process; after completing the revenue sharing and settlement, encrypting and storing the optimized revenue sharing and settlement form and the revenue sharing and settlement data in the blockchain, and repeating the above process to execute the revenue sharing and settlement requests for the next time period; based on the above, this invention can effectively alleviate system issues in high-concurrency transaction scenarios. This invention reduces system pressure, optimizes resource utilization, and significantly improves the efficiency of revenue sharing. Furthermore, smart contracts enable dynamic compliance review and risk assessment of transactions, ensuring the accuracy and security of the revenue sharing process. This effectively adapts to the diverse needs of complex transaction scenarios and solves the problems of rigid rules and insufficient risk control capabilities in traditional methods. Simultaneously, the use of blockchain technology to encrypt and store revenue sharing results ensures data immutability, achieves high transparency and traceability in the settlement process, and reduces transaction disputes caused by data controversies. Compared to traditional revenue sharing methods, this invention optimizes the fund custody and circulation model, accelerates fund turnover, reduces fund retention time, and thus enhances the trust between the parties involved in the transaction and the reliability of the platform's operation. Attached Figure Description

[0057] Figure 1 is a flowchart of a blockchain-based revenue sharing and settlement method provided by the present invention;

[0058] Figure 2 is a schematic diagram of the structure of a revenue-sharing server provided by the present invention. Embodiments of the present invention

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

[0060] Please refer to Figure 1. This embodiment discloses a blockchain-based revenue sharing and settlement method. The blockchain includes a pre-deployed first smart contract and a second smart contract. The method is applied to a revenue sharing server and includes:

[0061] S101: Obtain a settlement request belonging to the current time period. The settlement request includes a settlement form consisting of multiple transactions to be settled. The multiple transactions to be processed come from different merchant nodes in the blockchain.

[0062] Each pending transaction must contain at least the buyer ID, merchant node ID, product type, payment method, transaction amount, and transaction time.

[0063] It should be understood that at the end of a preset time period (such as daily, hourly, or other agreed-upon periods), the blockchain packages all unsettled transaction records within that period into a settlement form and uploads it to the ledger server via a network interface (API). By centrally packaging unsettled transaction records within a certain period for unified processing, the ledger system can optimize resource scheduling, reduce real-time high-concurrency pressure, and improve overall processing efficiency and maintainability. When facing traffic peaks, it can improve the system's robustness and throughput while reducing latency and error handling burden, thereby significantly improving ledger efficiency and user experience.

[0064] S102: Call the first smart contract to perform risk and compliance review on each pending transaction in the settlement form, and adjust and optimize the settlement form according to the risk and compliance review results to obtain the optimized settlement form;

[0065] The risk and compliance audit results include one of the following: non-compliance, compliance but with risks, and compliance with no risks.

[0066] In implementation, each pending transaction in the settlement form undergoes risk and compliance review, and the settlement form is adjusted and optimized based on the results of the risk and compliance review, including:

[0067] a1: Get the i-th pending transaction in the settlement form, where the settlement form contains M pending transactions, and i and M are integers greater than zero;

[0068] a2: Retrieve the compliance review conditions agreed upon in the first smart contract, and determine whether the i-th pending transaction is compliant based on the compliance review conditions. If it is not compliant, take the non-compliance as the risk and compliance review result of the i-th pending transaction, remove the i-th pending transaction from the original form to be settled, and set i=i+1, return to step a1. If it is compliant, jump to step a3.

[0069] The compliance review conditions include, but are not limited to, restricted product types and restricted payment methods;

[0070] Specifically, determining whether the i-th pending transaction is compliant includes:

[0071] Get the merchant node ID in the i-th pending transaction;

[0072] Based on the mapping relationship between merchant node ID and compliance review conditions, obtain the corresponding compliance review conditions for the corresponding merchant node ID;

[0073] It should be noted that the system database pre-stores several mapping relationships between merchant node IDs and compliance review conditions. Each mapping relationship has a merchant node ID and a corresponding compliance review condition. The merchant node ID and the corresponding compliance review condition in each mapping relationship are manually associated and bound by technical personnel in advance. The compliance review conditions corresponding to each merchant node ID are all agreed upon by the merchant node in advance and determined by the e-commerce platform.

[0074] The corresponding compliance review conditions are compared with the information of the i-th pending transaction. If the information of the corresponding compliance review conditions is completely consistent with that of the i-th pending transaction, the i-th pending transaction is judged to be compliant; if the information of the corresponding compliance review conditions is not completely consistent with that of the i-th pending transaction, the i-th pending transaction is judged to be non-compliant.

[0075] For example, suppose the product type in the i-th pending transaction is athletic shoes, but athletic shoes are not among the product types restricted by the merchant node ID. Therefore, if there is a violation in the pending transaction, settling the pending transaction may easily lead to disputes over revenue sharing. To further explain, the merchant node may replace the transaction with a different product type in order to reduce revenue sharing commission or to avoid taxes.

[0076] a3: Retrieve the risk assessment conditions pre-agreed in the first smart contract, and determine whether the i-th pending transaction has any risk based on the risk assessment conditions. If there is a risk, mark the i-th pending transaction as compliant but with risk, and use compliant but with risk as the risk and compliance assessment result of the i-th pending transaction. Remove the i-th pending transaction from the original form to be settled, and set i=i+1, then return to step a1; if there is no risk, mark the i-th pending transaction as compliant and without risk, and use compliant and without risk as the risk and compliance assessment result of the i-th pending transaction, and set i=i+1, then return to step a1.

[0077] Specifically, the risk assessment criteria are risk level scoring thresholds;

[0078] Specifically, determining whether the i-th pending transaction has a risk includes:

[0079] Get the merchant node ID, transaction amount, and transaction time of the i-th pending transaction;

[0080] Based on the mapping relationship between merchant node IDs and risk analysis data, extract the corresponding risk analysis data for each merchant node ID;

[0081] The risk analysis data includes the average transaction amount, standard deviation of transaction amount, average transaction time, and standard deviation of transaction time for each corresponding merchant node ID.

[0082] It should be noted that: the system database pre-stores several mapping relationships between merchant node IDs and risk analysis data. Each mapping relationship contains a merchant node ID and its corresponding risk analysis data. The merchant node ID and its corresponding risk analysis data in each mapping relationship are manually associated and bound by technical personnel in advance. The risk analysis data corresponding to each merchant node ID is generated based on the merchant node's historical compliant transaction behavior.

[0083] It is worth noting that since the risk analysis data is generated based on the historical compliant transaction behavior of the corresponding merchant nodes, the average transaction amount, standard deviation of transaction amount, average transaction time, and standard deviation of transaction time in the risk analysis data are dynamically changing, rather than remaining constant. Dynamically limiting the risk analysis data based on the normal transaction behavior of merchant nodes helps the first smart contract to dynamically review the compliance and risk of transactions to be processed, thereby improving the efficiency of revenue sharing and settlement.

[0084] Input the transaction amount, the average transaction amount, and the standard deviation of the transaction amount into the predefined amount risk scoring function. In the process, the amount risk score of the i-th pending transaction is obtained;

[0085] Among them, the predefined monetary risk scoring function The expression is as follows:

[0086] ;

[0087] In the formula: Let i be the transaction amount in the i-th pending transaction; This represents the average transaction amount belonging to the corresponding merchant node ID. This represents the standard deviation of the transaction amount belonging to the corresponding merchant node ID;

[0088] Input the trading time, the average trading time, and the standard deviation of the trading time into a predefined time risk scoring function. In the process, the time risk score of the i-th pending transaction is obtained;

[0089] Wherein, the predefined time risk scoring function The expression is as follows:

[0090] ;

[0091] In the formula: Let i be the transaction time of the i-th pending transaction; This represents the average transaction time for the corresponding merchant node ID. This represents the standard deviation of the transaction time belonging to the corresponding merchant node ID;

[0092] Calculate the risk level score of the i-th pending transaction based on the amount risk score and the time risk score;

[0093] The formula for calculating the risk level score is as follows:

[0094] ;

[0095] In the formula: Score the risk level of the i-th pending transaction. and For a risk weight greater than 1, ;

[0096] The risk level score is compared with the risk level score threshold in the risk review conditions. If the risk level score is greater than or equal to the risk level score threshold, the i-th pending transaction is determined to have risk; if the risk level score is less than the risk level score threshold, the i-th pending transaction is determined to have no risk.

[0097] a4: Repeat steps a1 to a3 above until i=M, then end the loop, complete the adjustment and optimization of the form to be settled, and obtain the optimized form to be settled.

[0098] It should be understood that pending transactions that are non-compliant or compliant but pose risks are then handed over to manual review. This not only reduces the workload of manual review but also ensures the efficiency of some transaction settlement.

[0099] S103: Call the second smart contract to perform settlement on the optimized form to be settled, and record the settlement data generated during the settlement process;

[0100] In implementation, the process of splitting accounts for the optimized pending settlement form includes:

[0101] b1: Obtain the j-th pending transaction from the optimized settlement form, wherein the optimized settlement form contains N pending transactions, j and N are integers greater than zero, and N≤M;

[0102] b2: Obtain the merchant node ID in the j-th pending transaction, and retrieve the corresponding revenue sharing rule in the second smart contract based on the mapping relationship between the merchant node ID and the revenue sharing rule; the revenue sharing rule includes at least the revenue sharing amount ratio and the revenue sharing participant nodes;

[0103] It should be noted that: the system database pre-stores several mapping relationships between merchant node IDs and revenue sharing rules. Each mapping relationship has a merchant node ID and a corresponding revenue sharing rule. The merchant node ID and the corresponding revenue sharing rule in each mapping relationship are manually associated and bound by technical personnel in advance. The revenue sharing rule corresponding to each merchant node ID is formed in advance according to the mutual agreement of each revenue sharing participant node.

[0104] The revenue sharing participants include, but are not limited to, merchant nodes, e-commerce platform nodes, and bank nodes.

[0105] b3: Calculate the multiple distribution amounts of the j-th pending transaction according to the corresponding distribution rules, and allocate the transaction amount of the j-th pending transaction to the private wallet address of each distribution participant node according to the distribution amount, and let j=j+1, then return to step b1.

[0106] b4: Repeat steps b1 to b3 above until j=N, then end the loop and complete the settlement of the optimized settlement form.

[0107] It should be noted that the transaction amount of the j-th pending transaction is stored in a virtual account in advance in the form of "virtual splitting", that is, the e-commerce platform applies to the banking institution for a virtual account for fund custody. Therefore, the fund turnover no longer goes through the e-commerce platform.

[0108] Further understanding reveals that traditional e-commerce platforms mostly employ a "two-tier clearing" method for revenue sharing and settlement, which is an extension of the "one-tier clearing" method. "One-tier clearing" refers to the process where, after a payment transaction is completed, funds are directly cleared and settled through a compliant payment institution (such as a licensed third-party payment company or bank), transferring the funds to the recipient's (such as the merchant's) account in a single transaction. "Two-tier clearing," on the other hand, means that the user's payment is not directly cleared from the licensed payment institution to the recipient, but rather redistributed by an unlicensed intermediary or unauthorized entity. Then the funds are transferred to the final recipient's account; that is, the funds paid by the user go through one or more intermediaries between the payment institution and the final recipient. However, this creates an informal secondary clearing process, which is often unregulated or non-compliant. Therefore, "secondary clearing" is often regarded as a violation by regulatory agencies because unlicensed institutions or individuals acting as intermediaries not only increase the risk of misappropriation, delayed clearing, or money laundering, but also harm the rights and interests of users and merchants. As a result, the "airborne revenue sharing" settlement model has been applied to existing e-commerce platforms.

[0109] It is worth noting that although the "airborne revenue sharing" method improves the security of funds by bypassing the e-commerce platform, it still has shortcomings in terms of revenue sharing efficiency and security. It can easily cause funds to remain in the escrow account for a long time, and it lacks the traceability of revenue sharing and settlement results.

[0110] The settlement data includes at least multiple pending transactions that have completed settlement, multiple settlement amounts, the corresponding settlement participant node for each settlement amount, and the private wallet address of each settlement participant node.

[0111] S104: After completing the settlement, the optimized settlement form and settlement data are encrypted and stored in the blockchain, and the above process is repeated to execute the settlement request for the next time period.

[0112] In implementation, the process of encrypting and storing the optimized settlement form and revenue sharing data in the blockchain includes:

[0113] The pending settlement form and the split settlement data are merged to generate the split settlement result data;

[0114] The settlement results data are segmented to obtain multiple data segments.

[0115] It should be noted that the fragmentation process includes, but is not limited to, one of the following methods: horizontal fragmentation, vertical fragmentation, or hybrid fragmentation.

[0116] Each data shard is merged in a staggered manner to obtain multiple merged shards;

[0117] It should be noted that staggered merging of each data shard refers to non-corresponding association binding of each data shard. For example, suppose the settlement result data is sharded to obtain 3 data shards, namely A1, B1 and C1. In staggered merging, A1 and B1 will be merged to obtain merged shard A1B1, A1 and C1 will be merged to obtain merged shard A1C1, and B1 and C1 will be merged to obtain B1C1.

[0118] It should be understood that by merging the misaligned data, during the data restoration process, as long as any two merged blocks (limited to the above example scenario) are obtained and the duplicate parts in the merged blocks are compared and removed, the complete accounting and settlement result data can be restored. This greatly enhances the traceability and reproducibility of the accounting and settlement result data.

[0119] Each merged shard is hashed to form multiple blocks and a hash index for each block, and each block is stored on the blockchain according to the hash index.

[0120] It should be noted that the hash calculation uses either the SHA-256 or SHA-3 hash algorithm.

[0121] By employing a centralized processing mechanism with preset time periods, the system pressure under high-concurrency transaction scenarios is effectively alleviated, resource utilization is optimized, and the efficiency of revenue sharing is significantly improved. Furthermore, smart contracts enable dynamic compliance review and risk assessment of transactions, ensuring the accuracy and security of the revenue sharing process. This effectively adapts to the diverse needs of complex transaction scenarios and solves the problems of rigid rules and insufficient risk control capabilities in traditional methods. Simultaneously, the encrypted storage of revenue sharing settlement results using blockchain technology ensures the immutability of data, achieving high transparency and traceability in the settlement process and reducing transaction disputes caused by data controversies. Compared to traditional revenue sharing methods, this invention optimizes the fund custody and circulation model, accelerates fund turnover, reduces fund retention time, thereby enhancing the trust between the parties involved in the transaction and the reliability of the platform's operation. Example 2

[0122] Please refer to Figure 2. This embodiment discloses a revenue-sharing server, including a memory, a processor, and a computer program stored on the memory and running on the processor. When the processor executes the computer program, it implements any of the blockchain-based revenue-sharing settlement methods described above.

[0123] Since the ledger server described in this embodiment is the ledger server used to implement the blockchain-based ledger settlement method described in this application embodiment, those skilled in the art can understand the specific implementation method and various variations of the ledger server in this embodiment based on the blockchain-based ledger settlement method described in this application embodiment. Therefore, how the ledger server implements the method in this application embodiment will not be described in detail here. As long as those skilled in the art implement the ledger server used in the blockchain-based ledger settlement method described in this application embodiment, it falls within the scope of protection of this application. Example 3

[0124] This embodiment discloses a computer-readable storage medium, including a memory, a processor, and a computer program stored on the memory and running on the processor. When the processor executes the computer program, it implements any of the blockchain-based revenue sharing methods described above.

[0125] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters, weights, and thresholds in the formulas are set by those skilled in the art according to the actual situation.

[0126] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired or wireless network. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0127] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this invention can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0128] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0129] In the several embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only one method, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0130] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0131] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0132] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

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

Claims

1. A blockchain-based revenue-sharing settlement method, characterized in that, The blockchain includes a pre-deployed first smart contract and a second smart contract. The method is applied to a ledger server and includes: Obtain the revenue sharing and settlement request within the current time period. The revenue sharing and settlement request contains a settlement form consisting of multiple transactions to be settled. These multiple transactions to be processed come from different merchant nodes in the blockchain. The first smart contract is invoked to perform risk and compliance audits on each pending transaction in the settlement form, and the settlement form is adjusted and optimized based on the risk and compliance audit results to obtain the optimized settlement form. The second smart contract is invoked to perform revenue sharing and settlement on the optimized pending settlement form, and the revenue sharing and settlement data generated during the settlement process is recorded. After the settlement is completed, the optimized settlement form and settlement data are encrypted and stored in the blockchain, and the above process is repeated to execute the settlement request for the next time period.

2. The blockchain-based revenue sharing and settlement method according to claim 1, characterized in that, Each pending transaction must contain at least the buyer ID, merchant node ID, product type, payment method, transaction amount, and transaction time.

3. The blockchain-based revenue sharing and settlement method according to claim 2, characterized in that, The risk and compliance audit results include one of the following: non-compliance, compliance but with risks, and compliance with no risks. Specifically, each pending transaction in the settlement form undergoes risk and compliance review, and the settlement form is adjusted and optimized based on the results of the risk and compliance review, including: a1: Get the i-th pending transaction in the settlement form, where the settlement form contains M pending transactions, and i and M are integers greater than zero; a2: Retrieve the compliance review conditions agreed upon in the first smart contract, and determine whether the i-th pending transaction is compliant based on the compliance review conditions. If it is not compliant, take the non-compliance as the risk and compliance review result of the i-th pending transaction, remove the i-th pending transaction from the original form to be settled, and set i=i+1, return to step a1. If it is compliant, jump to step a3. The compliance review conditions include, but are not limited to, restricted product types and restricted payment methods; a3: Retrieve the risk assessment conditions pre-agreed in the first smart contract, and determine whether the i-th pending transaction has any risk based on the risk assessment conditions. If there is a risk, mark the i-th pending transaction as compliant but with risk, and use compliant but with risk as the risk and compliance assessment result of the i-th pending transaction. Remove the i-th pending transaction from the original form to be settled, and set i=i+1, then return to step a1; if there is no risk, mark the i-th pending transaction as compliant and without risk, and use compliant and without risk as the risk and compliance assessment result of the i-th pending transaction, and set i=i+1, then return to step a1. Specifically, the risk assessment criteria are risk level scoring thresholds; a4: Repeat steps a1 to a3 until i=M, then end the loop, complete the adjustment and optimization of the form to be settled, and obtain the optimized form to be settled.

4. The blockchain-based revenue sharing and settlement method according to claim 3, characterized in that, The determination of whether the i-th pending transaction is compliant includes: Get the merchant node ID in the i-th pending transaction; Based on the mapping relationship between merchant node ID and compliance review conditions, obtain the corresponding compliance review conditions for the corresponding merchant node ID; The corresponding compliance review conditions are compared with the information of the i-th pending transaction. If the information of the corresponding compliance review conditions is completely consistent with that of the i-th pending transaction, the i-th pending transaction is judged to be compliant; if the information of the corresponding compliance review conditions is not completely consistent with that of the i-th pending transaction, the i-th pending transaction is judged to be non-compliant.

5. The blockchain-based revenue sharing and settlement method according to claim 4, characterized in that, The determination of whether the i-th pending transaction has a risk includes: Get the merchant node ID, transaction amount, and transaction time of the i-th pending transaction; Based on the mapping relationship between merchant node IDs and risk analysis data, extract the corresponding risk analysis data for each merchant node ID; The risk analysis data includes the average transaction amount, standard deviation of transaction amount, average transaction time, and standard deviation of transaction time for each corresponding merchant node ID. Input the transaction amount, the average transaction amount, and the standard deviation of the transaction amount into the predefined amount risk scoring function. In the process, the amount risk score of the i-th pending transaction is obtained; Among them, the predefined monetary risk scoring function The expression is as follows: ； In the formula: Let i be the transaction amount in the i-th pending transaction; This represents the average transaction amount belonging to the corresponding merchant node ID. This represents the standard deviation of the transaction amount belonging to the corresponding merchant node ID; Input the trading time, the average trading time, and the standard deviation of the trading time into a predefined time risk scoring function. In the process, the time risk score of the i-th pending transaction is obtained; Wherein, the predefined time risk scoring function The expression is as follows: ； In the formula: Let i be the transaction time of the i-th pending transaction; This represents the average transaction time for the corresponding merchant node ID. This represents the standard deviation of the transaction time belonging to the corresponding merchant node ID; Calculate the risk level score of the i-th pending transaction based on the amount risk score and the time risk score; The formula for calculating the risk level score is as follows: ； In the formula: Score the risk level of the i-th pending transaction. and For a risk weight greater than 1, ； The risk level score is compared with the risk level score threshold in the risk review conditions. If the risk level score is greater than or equal to the risk level score threshold, the i-th pending transaction is determined to have risk; if the risk level score is less than the risk level score threshold, the i-th pending transaction is determined to have no risk.

6. The blockchain-based revenue sharing and settlement method according to claim 5, characterized in that, The process of splitting the bill for the optimized pending settlement form includes: b1: Obtain the j-th pending transaction from the optimized settlement form, wherein the optimized settlement form contains N pending transactions, j and N are integers greater than zero, and N≤M; b2: Obtain the merchant node ID in the j-th pending transaction, and retrieve the corresponding revenue sharing rule in the second smart contract based on the mapping relationship between the merchant node ID and the revenue sharing rule; the revenue sharing rule includes at least the revenue sharing amount ratio and the revenue sharing participant nodes; The revenue-sharing participants include merchant nodes, e-commerce platform nodes, and bank nodes. b3: Calculate the multiple distribution amounts of the j-th pending transaction according to the corresponding distribution rules, and allocate the transaction amount of the j-th pending transaction to the private wallet address of each distribution participant node according to the distribution amount, and let j=j+1, then return to step b1. b4: Repeat steps b1 to b3 above until j=N, then end the loop and complete the settlement of the optimized settlement form.

7. The blockchain-based revenue sharing and settlement method according to claim 6, characterized in that, The revenue sharing and settlement data includes at least multiple pending transactions that have completed revenue sharing and settlement, multiple revenue sharing amounts that have completed revenue sharing and settlement, the corresponding revenue sharing participant node for each revenue sharing amount, and the private wallet address of each revenue sharing participant node.

8. The blockchain-based revenue sharing and settlement method according to claim 7, characterized in that, The step of encrypting and storing the optimized settlement form and revenue sharing data in the blockchain includes: The pending settlement form and the split settlement data are merged to generate the split settlement result data; The settlement results data are segmented to obtain multiple data segments. Each data shard is merged in a staggered manner to obtain multiple merged shards; Each merged shard is hashed to form multiple blocks and a hash index for each block, and each block is stored on the blockchain according to the hash index.

9. A revenue-sharing server, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the blockchain-based revenue sharing method according to any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the blockchain-based revenue sharing and settlement method according to any one of claims 1-8.

Images