Method, device, storage medium and electronic device for detecting resource processing event

Abstract

The present disclosure provides a method, device and electronic equipment for detecting a resource processing event. The method comprises the following steps: obtaining a resource processing event detection request; constructing block data according to resource pre-advance pledge object information and resource processing event information, wherein the block data comprises an association relationship between the pre-advance pledge object information and the resource processing event information; sending the block data to a preset blockchain network for consensus processing, wherein a consensus node in the preset blockchain network performs conflict detection on the block data according to a resource processing relationship to obtain a consensus result, and the consensus node at least comprises a pre-advance institution node corresponding to pre-advance institution information; receiving the consensus result returned by the preset blockchain network, and determining a detection result corresponding to the resource processing event detection request according to the consensus result. The method can accurately detect the resource processing event and avoid risks caused by abnormal resource processing events.

Description

Technical Field

[0001] This disclosure relates to the field of blockchain, and more particularly to a method, apparatus, storage medium, and electronic device for detecting resource processing events. Background Technology

[0002] With the rapid development of internet technology, internet applications have emerged in various industries. For example, in the financial industry, online financing is used for financing management. Financing refers to a series of fundraising activities undertaken by enterprises or individuals to meet their funding needs. It can be understood as the process by which borrowers obtain funds from lenders through online orders. These funds can be used for business operations, expansion, investment, or personal consumption.

[0003] Order financing is a business where, when a borrower initiates a financing application on a financing platform, the platform provides the corresponding orders. The lender then selects these orders as the objects of their financing on the platform, and the platform generates a financing contract based on the selected orders. The lender then disburses funds based on the financing contract.

[0004] However, the current lack of effective testing before financing contracts take effect leads to abnormal risks. Summary of the Invention

[0005] This disclosure provides a method, apparatus, storage medium, and electronic device for detecting resource processing events. The method can accurately detect resource processing events and avoid risks caused by abnormal resource processing events.

[0006] The first aspect of this disclosure provides a method for detecting resource processing events, including:

[0007] Obtain a resource processing event detection request. The resource processing event detection request includes information about the resource processing event to be detected. The resource processing event information includes information about the resource prepayment collateral object and the prepayment institution.

[0008] Block data is constructed based on information on resource pre-payment mortgage objects and resource processing event information. The block data includes the relationship between resource pre-payment mortgage object information and resource processing event information.

[0009] Block data is sent to a pre-set blockchain network for consensus processing. The pre-set blockchain network includes multiple historical block data. The historical block data contains the resource processing relationships between multiple resource pre-sale collateral objects and multiple resource processing events. The consensus nodes in the pre-set blockchain network perform conflict detection on the block data based on the resource processing relationships to obtain a consensus result. The consensus nodes include at least the pre-sale institution nodes corresponding to the pre-sale institution information.

[0010] Receive the consensus result returned by the preset blockchain network, and determine the detection result corresponding to the resource processing event detection request based on the consensus result.

[0011] A second aspect of this disclosure provides a device for detecting resource processing events, comprising:

[0012] The acquisition unit is used to acquire resource processing event detection requests. The resource processing event detection requests include information on resource processing events to be detected. The resource processing event information includes information on resource prepayment collateral objects and prepayment institutions.

[0013] The construction unit is used to construct block data based on the resource pre-payment mortgage object information and resource processing event information. The block data includes the association between the resource pre-payment mortgage object information and the resource processing event information.

[0014] The sending unit is used to send block data to a preset blockchain network for consensus processing. The preset blockchain network includes multiple historical block data. The historical block data contains the resource processing relationships between multiple resource pre-sale collateral objects and multiple resource processing events. The consensus nodes in the preset blockchain network perform conflict detection on the block data according to the resource processing relationships to obtain the consensus result. The consensus nodes include at least the pre-sale institution nodes corresponding to the pre-sale institution information.

[0015] The receiving unit is used to receive the consensus result returned by the preset blockchain network and determine the detection result corresponding to the resource processing event detection request based on the consensus result.

[0016] Optionally, in some embodiments, the building unit includes:

[0017] The first construction subunit is used to construct the first data object based on the information of the resource pre-payment mortgage object;

[0018] The second construction subunit is used to construct a second data object based on resource processing event information;

[0019] The third construction subunit is used to construct a third data object based on the association between the resource pre-payment mortgage object information and the resource processing event information, and to construct block data based on the first data object, the second data object and the third data object.

[0020] Optionally, in some embodiments, the third building subunit includes:

[0021] The first acquisition module is used to acquire the object number corresponding to the resource prepayment mortgage object information and the event number corresponding to the resource processing event information.

[0022] The query module is used to query the block number corresponding to the resource prepayment mortgage object information in historical block data, and to query the block number corresponding to the resource processing event information.

[0023] The first construction module is used to construct a third data object based on the object number, event number, the block number pointed to by the object, and the block number pointed to by the event.

[0024] Optionally, in some embodiments, the third building subunit includes:

[0025] The second acquisition module is used to acquire the hash value of the target historical block data with the highest block height in the historical block data of the preset blockchain network, and obtain the parent hash;

[0026] The second building module is used to construct a block body based on the first data object, the second data object, and the third data object;

[0027] The third construction module is used to construct the block header based on the encoding information corresponding to the first data object, the second data object, and the third data object, as well as the parent hash, and to determine the block data based on the block body and the block header.

[0028] Optionally, in some embodiments, the transmitting unit includes:

[0029] The first acquisition subunit is used to acquire the advance application object information corresponding to the resource advance mortgage object information, and to acquire the first associated advance institution information associated with the advance application object information;

[0030] The first determining subunit is used to determine multiple target pre-supporting organization nodes among multiple pre-supporting organization nodes based on the first associated pre-supporting organization information;

[0031] The first sending subunit is used to send block data to the target pre-support organization node for consensus.

[0032] Optionally, in some embodiments, the receiving unit includes:

[0033] The receiving subunit is used to receive multiple consensus results returned by multiple consensus nodes;

[0034] Extract sub-units to extract conflict detection results from each consensus result, resulting in multiple conflict detection results;

[0035] The second determining subunit is used to determine the detection result corresponding to the resource processing event detection request as unqualified when there is a target conflict detection result indicating that the conflict detection is unqualified among multiple conflict detection results.

[0036] Optionally, in some embodiments, the receiving unit further includes:

[0037] The generation sub-unit is used to generate feedback information indicating that the detection failed.

[0038] The second sending subunit is used to send feedback information to the pre-supporting organization corresponding to the pre-supporting organization information.

[0039] Optionally, in some embodiments, the receiving unit further includes:

[0040] The third determining subunit is used to determine the detection result corresponding to the resource processing event detection request as qualified when there is no target conflict detection result indicating that the conflict detection is unqualified among multiple conflict detection results.

[0041] Add sub-units to add block data to the local blockchain;

[0042] The third sending subunit is used to send block data to a preset blockchain network for blockchain updates.

[0043] Optionally, in some embodiments, the receiving unit further includes:

[0044] The second acquisition subunit is used to acquire the settlement message for the settlement of the resource prepayment mortgage object corresponding to the information of the resource prepayment mortgage object;

[0045] The update subunit is used to update the resource prepayment collateral object information according to the settlement message, and to construct settlement block data based on the updated resource prepayment collateral object information and resource processing event information. The settlement block data includes the association between the updated resource prepayment collateral object information and resource processing event information.

[0046] The fourth sending subunit is used to send settlement block data to the preset blockchain network.

[0047] A third aspect of this disclosure provides a consensus apparatus for block data, comprising:

[0048] The first search unit is used to search for information on the second associated pre-payment institution that is associated with the information on the resource pre-payment mortgage object in historical block data based on the association relationships contained in the block data;

[0049] The second search unit is used to search for related historical resource processing events based on the information of the second associated pre-payment organization.

[0050] The conflict detection unit is used to perform conflict detection on block data based on the event status of historical resource processing events to obtain consensus results.

[0051] Optionally, in some embodiments, the collision detection unit includes:

[0052] The first determining subunit is used to determine that a conflict exists when there is an unfinished target historical resource processing event in the historical resource processing events.

[0053] The second determining subunit is used to determine that there is no conflict when there are no unfinished historical resource processing events in the historical resource processing events.

[0054] The third determining subunit is used to determine the consensus result based on the conflict detection result.

[0055] The fourth aspect of this disclosure provides a storage medium storing a computer program that, when executed by a processor, implements the resource processing event detection method as described in the first aspect.

[0056] The fifth aspect of this disclosure provides an electronic device including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the resource processing event detection method as described in the first aspect.

[0057] The sixth aspect of this disclosure provides a computer program product comprising a computer program that is read and executed by a processor of an electronic device, causing the electronic device to perform the resource processing event detection method as described in the first aspect.

[0058] Therefore, the resource processing event detection method provided in this disclosure includes: obtaining a resource processing event detection request, the resource processing event detection request including information on the resource processing event to be detected, the resource processing event information including information on resource pre-payment collateral objects and pre-payment institutions; constructing block data based on the resource pre-payment collateral object information and the resource processing event information, the block data including the association relationship between the pre-payment collateral object information and the resource processing event information; sending the block data to a preset blockchain network for consensus processing, the preset blockchain network including multiple historical block data, the historical block data containing resource processing relationships between multiple resource pre-payment collateral objects and multiple resource processing events, consensus nodes in the preset blockchain network performing conflict detection on the block data based on the resource processing relationships to obtain a consensus result, the consensus nodes including at least the pre-payment institution node corresponding to the pre-payment institution information; receiving the consensus result returned by the preset blockchain network, and determining the detection result corresponding to the resource processing event detection request based on the consensus result.

[0059] This method generates block data by analyzing the pre-payment collateral information, resource processing event information, and the relationship between the two contained in the resource processing event, and uploads the block data to the blockchain for consensus. During the consensus process, each consensus node can perform conflict detection on the relationship based on the historical resource processing event information stored on the blockchain to avoid conflicts between the pre-payment collateral information and the resource processing event information, thereby ensuring the security of the resource processing event.

[0060] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objectives and other advantages of this disclosure may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0061] The accompanying drawings are provided to further understand the technical solutions of this disclosure and constitute a part of the specification. They are used together with the embodiments of this disclosure to explain the technical solutions of this disclosure and do not constitute a limitation on the technical solutions of this disclosure.

[0062] Figure 1 This is a schematic diagram of a blockchain consensus system according to an embodiment of the present disclosure;

[0063] Figure 2 This is a flowchart illustrating a method for detecting resource processing events in an embodiment of this disclosure;

[0064] Figure 3 This is a schematic diagram of the data structure of block data in one embodiment of this disclosure;

[0065] Figure 4 This is another flowchart illustrating the resource processing event detection method in this embodiment of the present disclosure;

[0066] Figure 5 This is a schematic diagram of the UTXO structure in an embodiment of this disclosure;

[0067] Figure 6 This is another schematic diagram of the data structure in an embodiment of this disclosure;

[0068] Figure 7 This is a schematic diagram of block tracing in one embodiment of the present disclosure;

[0069] Figure 8 This is a schematic diagram of the structure of a resource processing event detection device according to an embodiment of this disclosure;

[0070] Figure 9 This is a terminal structure diagram of each method in one embodiment of this disclosure;

[0071] Figure 10This is a server structure diagram of various methods in one embodiment of this disclosure. Detailed Implementation

[0072] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this disclosure.

[0073] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “corresponding to,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0074] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0075] In this disclosure, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0076] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0077] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. The terminology used herein is for the purpose of describing embodiments of this disclosure only and is not intended to be limiting of this disclosure.

[0078] The following explains some of the terms used in the embodiments of this disclosure.

[0079] Order financing: Order financing refers to short-term financing provided by a bank to the order recipient after the buyer and seller have signed an order contract. This financing, based on the valid order contract and using the expected sales revenue as the primary source of repayment, addresses the recipient's funding needs for raw material procurement, production organization, construction, and goods transportation. For example, a buyer places an order for goods or services on an e-commerce platform, and this order is subsequently used to generate a financing order on a loan facilitation platform. The bank, as the lender, will browse and select suitable financing orders on the platform, generate an order contract, and provide financing—that is, disburse the corresponding funds to the seller (i.e., the merchant on the e-commerce platform). This funding may be used to meet the seller's funding needs, such as inventory purchases and operating costs.

[0080] Seller: In this disclosure, the seller specifically refers to the party that provides goods or services based on an order, or the seller, and is also the borrower in the "order financing" transaction.

[0081] E-commerce platform: refers to the platform through which transactions and related services are conducted via the Internet or electronic transaction methods. It represents the digitalization and networking of various aspects of traditional business activities. In this embodiment of the disclosure, the e-commerce platform specifically refers to the platform where the seller's order is located.

[0082] Borrower: The party requesting funds. In this embodiment of the disclosure, the borrower specifically refers to the party initiating a financing request in an order financing transaction.

[0083] Lender: The source of funds. In this disclosed embodiment, the lender specifically refers to the institution that provides funds to the seller in order financing transactions.

[0084] Blockchain: A decentralized distributed ledger that is block-chained, immutable, secure and reliable. It combines distributed storage, peer-to-peer transmission, consensus mechanisms, cryptography and other technologies to record transactions and information through a continuously growing chain of data blocks, ensuring data security and transparency. The embodiments disclosed herein do not limit the specific implementation of blockchain.

[0085] Consortium blockchain: A consortium blockchain is a type of blockchain that lies between public and private blockchains. It improves transaction speed and efficiency by sharing data among pre-selected nodes, while maintaining a certain level of privacy.

[0086] Consensus Mechanism: The consensus mechanism is a core concept in blockchain technology. It involves how to ensure that all nodes in a distributed network reach a consensus on the consistency of data. That is, through a series of algorithms and rules, nodes in the network are allowed to participate in the verification process of transactions, ensuring that once a transaction is recorded on the blockchain, it is difficult to tamper with or delete, thus providing a high level of security for the blockchain.

[0087] When a borrower initiates a financing application to a lender through a loan facilitation platform, the lender's business system selects the order and marks it as one of the targets of this financing application. If the platform connects to multiple lenders and allows borrowers to initiate financing applications to multiple lenders "simultaneously," it is possible that the same order may be marked as a financing target by two or more lender systems. This could result in a single order being used for multiple financings, potentially leading to insufficient settlement funds to repay the multiple loans corresponding to those financings, thus amplifying the lender's bad debt risk. In solutions to address the risk of multiple loans for a single order, if the platform restricts borrowers from obtaining financing from other lenders before repaying existing financing, it may negatively impact the product experience for both borrowers and lenders, such as weakening the lender's marketing efforts to adjust financing interest rates. If the loan facilitation platform allocates orders for financing, it needs to have the appropriate permissions.

[0088] To address the aforementioned issues, this disclosure provides a method for detecting resource processing events. The method includes: acquiring a resource processing event detection request, the request including information about a resource processing event to be detected, the information including information about resource pre-payment collateral objects and pre-payment institutions; constructing block data based on the resource pre-payment collateral object information and the resource processing event information, the block data including the association between the pre-payment collateral object information and the resource processing event information; sending the block data to a preset blockchain network for consensus processing, the preset blockchain network including multiple historical block data, the historical block data containing resource processing relationships between multiple resource pre-payment collateral objects and multiple resource processing events, consensus nodes in the preset blockchain network performing conflict detection on the block data based on the resource processing relationships to obtain a consensus result, the consensus nodes including at least the pre-payment institution node corresponding to the pre-payment institution information; receiving the consensus result returned by the preset blockchain network, and determining the detection result corresponding to the resource processing event detection request based on the consensus result.

[0089] This method generates block data by analyzing the pre-payment collateral information, resource processing event information, and the relationship between the two contained in the resource processing event, and uploads the block data to the blockchain for consensus. During the consensus process, each consensus node can perform conflict detection on the relationship based on the historical resource processing event information stored on the blockchain to avoid conflicts between the pre-payment collateral information and the resource processing event information, thereby ensuring the security of the resource processing event.

[0090] See Figure 1 The blockchain consensus system shown includes a blockchain network and an external network. The blockchain network, in this context, refers to the network that reaches a consensus on transactions to be added to the blockchain before adding them; it includes multiple consensus nodes 110. The external network refers to the network that generates transactions to be added to the blockchain but does not actually add them; it includes multiple transaction generating nodes 120. The external network can connect to other networks or systems outside the blockchain network. In blockchain technology, the external network serves as a channel for communication and interaction with the blockchain network. Consensus nodes 110 are the blockchain nodes. Transaction generating nodes 120 do not need to participate in the on-chain consensus; their main function is to generate transactions to be added to the blockchain.

[0091] Consensus node 110 or transaction generator node 120 can be a server in the blockchain network or a terminal connected to the blockchain network; the specific form of consensus node 110 and transaction generator node 120 is not limited here. It can also be understood that... Figure 1 The blockchain network and external network shown can reside in different network environments. For example, typically, transaction generation node 120 is deployed in a public external network, while consensus node 110, running the blockchain consensus protocol, is deployed in a private consensus network. Consensus node 110 and transaction generation node 120 can interact through routing nodes, or they can transmit data directly without routing nodes. It should be noted that because the consensus network resides in a relatively secure private cloud, their mutual access is inherently secure due to the consensus mechanism, requiring no additional identity management or network control. However, transaction generation node 120 resides in a public network and may be accessed by other unidentified network terminals. Therefore, the access of transaction generation node 120 and other potential nodes to the consensus network needs to be strictly controlled.

[0092] The resource processing event detection method provided in this embodiment includes: a transaction generation node 120 obtaining a resource processing event detection request; the transaction generation node 120 constructing block data based on the resource pre-sale collateral object information and resource processing event information in the resource processing event detection request; the transaction generation node 120 sending the block data to a preset blockchain network for consensus processing; a consensus node 110 performing conflict detection on the block data based on the resource processing relationships between multiple resource pre-sale collateral objects and multiple resource processing events contained in historical block data to obtain a consensus result; the consensus node 110 feeding back the consensus result to the transaction generation node 120 through the preset blockchain network; and the transaction generation node 120 determining the detection result corresponding to the resource processing event detection request based on the consensus result.

[0093] This disclosure can be applied to various scenarios. For example, taking a resource processing event as a financing event, when a block containing financing information for a defined order is uploaded to the blockchain, consensus nodes in the consortium blockchain can reach a consensus on the block and generate a consensus result. Using the resource processing event detection method of this disclosure, based on the loan information, lender information, and association with the order in the block, the corresponding association can be queried in the historical blocks of the consortium blockchain nodes to perform conflict detection, thus avoiding the problem of multiple loans for a single order.

[0094] The above examples do not limit the scope of protection in this case.

[0095] General Description of the Disclosed Embodiments

[0096] According to one embodiment of this disclosure, a method for detecting resource processing events is provided. For example... Figure 2 The diagram shown is a flowchart illustrating a method for detecting resource processing events provided in this disclosure. This method can be applied to a resource processing event detection device, which can be integrated into an electronic device, specifically a terminal or a server. The resource processing event detection method may include:

[0097] Step 201: Obtain resource processing event detection request.

[0098] A resource processing event detection request can include information about the resource processing event to be detected. It can refer to a request to detect resource processing events based on this information. A resource processing event can refer to any event related to the use and allocation of resources in any scenario requiring resource management and allocation. The resource processing event information can include information about resource pre-payment collateral objects and pre-payment institutions. Specifically, it can be information about resource allocation events generated by the pre-payment institution based on the resource pre-payment collateral objects corresponding to the resource pre-payment collateral object information.

[0099] Information on collateral for resource advance payments can be information about specific assets provided as collateral for a loan, which are used as collateral to ensure loan repayment. Alternatively, it can be understood as providing an object that records information about the specific assets provided as collateral for the loan, including attributes such as the type, quantity, and quality of the resources, as well as the specific conditions and terms of the resource advance payment.

[0100] Information about advance payment institutions can be related to organizations or institutions that provide advance payment services. These institutions can be businesses, financial institutions, or other organizations that offer advance payment services, allowing individuals or businesses to access their credit lines in advance under specific conditions. In other words, they can provide liquidity support to help address short-term funding needs.

[0101] Resource processing event detection requests can be initiated by the pre-supporting organization corresponding to the pre-supporting organization information, or they can be generated proactively, such as periodically.

[0102] Step 202: Construct block data based on the information of resource pre-payment mortgage objects and resource processing event information.

[0103] Block data can be a data structure stored within a blockchain technology framework. It contains a series of data records organized into one or more blocks. Each block typically contains a set of transaction records or data records and is cryptographically linked to the previous block, forming a continuous and immutable data chain. In this embodiment, the block data can include the association between pre-payment collateral information and resource processing event information. That is, the block data can record both resource pre-payment collateral information and resource processing event information, and the resource pre-payment collateral corresponding to the pre-payment collateral information can be traced back to the resource pre-payment collateral in another block. The block data can record every key event in the lifecycle of the pre-payment collateral. It is understood that the associations in the current block data can be traced back to the most recently updated key event.

[0104] In one implementation, block data is constructed based on information about resource pre-payment collateral and resource processing events, including:

[0105] The first data object is constructed based on the information of the resource pre-payment mortgage object;

[0106] Construct a second data object based on resource processing event information;

[0107] A third data object is constructed based on the relationship between the resource pre-payment mortgage object information and the resource processing event information, and block data is constructed based on the first data object, the second data object and the third data object.

[0108] In this implementation, the first data object can be a data structure in the block, which can record object indication information in the resource prepayment collateral object information. This object indication information can identify the resource prepayment collateral object corresponding to the resource prepayment collateral object information, and can also record the basic data of the resource prepayment collateral object, such as creation time, collateral information and transaction conditions.

[0109] The second data object can be a data structure within a block, recording event indication information from resource processing event information. This event indication information identifies the resource processing event corresponding to the resource processing event information. The basic information of the resource processing event, such as transaction amount and transaction object, can be recorded in the second data object, or it can be recorded in other data structures within the block formed by the second data objects.

[0110] The third data object can be a data structure within the block that describes the relationship between the first and second data objects, ensuring that the block data reflects the connection between resource pre-sale collateral objects and resource processing events. This can be achieved, for example, by including references to resource pre-sale collateral objects and resource processing events, thereby creating a clear traceability path within the block.

[0111] In one implementation, a third data object is constructed based on the association between resource pre-payment collateral information and resource processing event information, including:

[0112] Obtain the object number corresponding to the resource prepayment mortgage object information and the event number corresponding to the resource processing event information;

[0113] In historical block data, query the block number corresponding to the resource prepayment mortgage object information, and query the block number corresponding to the resource processing event information;

[0114] Construct a third data object based on the object number, event number, the block number the object points to, and the block number the event points to.

[0115] In this implementation, the object number can be a unique identifier for the resource prepayment collateral object. It can identify the resource prepayment collateral object within a single block, and can also be used by a blockchain explorer to query detailed information about the resource prepayment collateral object, including the object's status, transaction history, etc. This increases the transparency and accessibility of the blockchain.

[0116] An event number can be a unique identifier for a resource processing event. It can identify a resource processing event within a single block and can also be used by a blockchain explorer to query detailed information about the resource processing event, including the event's status and triggering conditions. This increases the transparency and accessibility of the blockchain.

[0117] The object points to a block number that can be a block number on the blockchain. This number points to a block containing information about a specific resource pre-collateral object, providing a clear blockchain location, meaning that the location and status of the resource pre-collateral object on the blockchain can be directly traced.

[0118] The event-pointing block number can be the block number on the blockchain. This number points to the block containing information about a specific resource processing event, providing a clear blockchain location, meaning that the location and status of the resource processing event on the blockchain can be directly traced.

[0119] Third-party data objects can record the correspondence between object numbers and their corresponding block numbers based on the information of resource pre-sale collateral objects. This means that the resource pre-sale collateral object can be traced back to its corresponding block number by searching the corresponding relationship within the third-party data object based on the object number. Similarly, third-party data objects can record the correspondence between event numbers and their corresponding block numbers based on resource processing event information. This means that the resource processing event can be traced back to its corresponding relationship within the third-party data object based on the event number. Third-party data objects provide a comprehensive and detailed record of relationships for the blockchain network, facilitating transaction verification and ensuring the stability and security of the entire network.

[0120] For example, the data structure diagram 30 of this block data can be referred to Figure 3 As shown, it includes a first data object 31, a second data object 32 and a third data object 33. The third data object 33 can be used to trace back to the resource pre-sale collateral objects and resource processing events in historical blocks.

[0121] In one implementation, constructing block data based on a first data object, a second data object, and a third data object includes:

[0122] Obtain the hash value of the target historical block with the highest block height from the historical block data in the preset blockchain network to get the parent hash;

[0123] Construct a block body based on the first data object, the second data object, and the third data object;

[0124] The block header is constructed based on the encoding information corresponding to the first data object, the second data object, and the third data object, as well as the parent hash, and the block data is determined based on the block body and the block header.

[0125] In this embodiment, the target historical block data refers to the data of the target historical block in the blockchain network. The target historical block in this embodiment can be the block with the highest block height in the preset blockchain network. It can be understood that the block with the highest block height can also be called the "top" or "latest" block of the chain, that is, the latest block currently added to the chain in the preset blockchain network.

[0126] A parent hash can be a reference to the hash value of the previous block in the blockchain, also known as the previous block hash. Each block, in addition to containing transaction data, can also include a parent hash, which links each block to its predecessor, forming a chain structure. For example, suppose the latest block on the blockchain is block 10, with a block header hash value of 0000abcdef. When creating block 11, 0000abcdef can be included as the parent hash value of block 11.

[0127] A block body can be a component of a block in a blockchain. It can include the actual data records within the block, such as transaction records. It organizes transaction data together, typically in the form of a list or array, recording information such as asset transfers and contract executions. The block body can record first, second, and third data objects, containing references to resource pre-collateral objects and resource processing events, providing a traceability path for objects or events.

[0128] Encoding information refers to the process of converting data objects into a format that can be understood and processed by nodes in a blockchain network. This format is usually binary or a specific serialization format. In this embodiment of the disclosure, data in the block body can be converted into an encoded form for hash processing, that is, the first data object, the second data object, and the third data object can be converted into encoded information.

[0129] A block header can be a component of a block in a blockchain and can include key information used to link to the blockchain and verify the block's validity, such as the version number, parent hash, Merkle root, timestamp, difficulty target, and nonce. The version number indicates the block's version and identifies the version of the block's data structure to maintain backward compatibility during protocol updates. The Merkle root is the root hash of the Merkle tree of all transactions in the block, used to verify the integrity and consistency of transactions within the block. The timestamp records the time the block was created, typically a Unix timestamp, helping to ensure the blockchain's order and prevent blocks from being generated too quickly. The difficulty target adjusts the network's resource mining difficulty and, together with the nonce, is used for proof-of-work. The nonce is a random number used in proof-of-work; during resource mining, this value is changed to generate block hashes that meet the difficulty target. The data in the block header is also converted into encoded information. Based on the block header and its encoded information, a hash is performed to obtain the hash value of the current block, which is recorded in the Merkle root of the block header. The block header and block body are combined to form complete block data.

[0130] Step 203: Send the block data to the preset blockchain network for consensus processing.

[0131] A pre-defined blockchain network refers to a pre-established blockchain environment, including, for example, the definition of blockchain, its core characteristics, and specific application scenarios. Such a network can be public, permissioned, or federated, depending on the network's access permissions and governance structure. This disclosure uses a federated blockchain network as an example.

[0132] A pre-defined blockchain network can include multiple historical block data, meaning that the blockchain records every transaction and state change since its inception, and this data is organized into blocks.

[0133] Historical block data can contain the resource processing relationship between multiple resource pre-sale collateral objects and multiple resource processing events. Multiple resource pre-sale collateral objects may or may not include the resource pre-sale collateral object corresponding to the resource pre-sale collateral object information. Each historical block data records the association between a resource pre-sale collateral object and a resource processing event, that is, the corresponding resource pre-sale collateral object can be traced back based on the resource processing event.

[0134] Consensus nodes in a pre-defined blockchain network are nodes that maintain the network's operation and ensure data consistency. They can verify the legitimacy of transactions and create new blocks based on the consensus mechanism. Consensus nodes can also perform conflict detection on block data based on resource processing relationships to obtain a consensus result. This involves using historical block data stored in the node's blockchain data to perform conflict detection. Specifically, it queries the relationship between resource pre-staking collateral information and resource processing event information in the block data, retrieves the target pre-staking collateral corresponding to that information from the historical block data's resource processing relationships, and determines the consensus result based on whether the target pre-staking collateral corresponds to the pre-staking collateral information in the block data. Understandably, if the target pre-staking collateral does not correspond to the pre-staking collateral information in the block data, the consensus result is a failure; if the target pre-staking collateral corresponds to the pre-staking collateral information in the block data, the consensus result is a success. Among them, based on the transaction information recorded by each pre-payment institution, the node where the pre-payment institution is located can be used as the consensus node. That is, the consensus node includes at least the pre-payment institution node corresponding to the pre-payment institution information. The pre-payment institution node can be understood as a specific node representing the pre-payment institution in participating in the operation and maintenance of the blockchain network.

[0135] Before performing conflict detection on the block data, the consensus node can first verify the block data using a consensus algorithm. This consensus algorithm can be Practical Byzantine Fault Tolerance (PBFT), Raft, PoET, etc. In this embodiment, conflict detection can be performed concurrently with the consensus algorithm or after the consensus algorithm has been verified; no limitation is made here.

[0136] Consensus in PBFT is achieved through three phases: Pre-prepare, Prepare, and Commit. In the Pre-prepare phase, the master node broadcasts transaction proposals to all replica nodes. In the Prepare phase, each replica node verifies the transaction and broadcasts its prepare information. Once the master node has collected more than two-thirds of the prepare information, it enters the Commit phase and broadcasts a commit message. Once the replica nodes receive the commit message, they execute the transactions and store the results. This process ensures that consensus can still be reached even in the presence of Byzantine nodes (i.e., malicious or faulty nodes).

[0137] The Raft consensus mechanism achieves consensus through leader election and log replication. The leader node receives client requests and replicates these requests as log entries to all follower nodes. This process is called log replication. Follower nodes, upon receiving log entries, append them to their own logs if they match the leader's. Once the leader has collected confirmation from a majority of nodes (including itself), the log entries are committed. This process ensures consistent log acceptance by all honest nodes, even in the presence of faulty nodes.

[0138] The PoET consensus mechanism achieves consensus by randomly selecting a leader. Each node generates a random wait time within its Trusted Execution Environment (TEE), which is invisible to other nodes. After waiting, a node has the opportunity to become the leader and create a new block. The randomness of the wait time ensures fair leader selection. Once the leader creates a block and broadcasts it to the network, other nodes verify its validity. If the block is valid, the nodes accept it and proceed to the next round of leader election. PoET's consensus process does not require direct communication between nodes; instead, it relies on the security of the TEE and the randomness of the wait time.

[0139] In one implementation, sending block data to a pre-defined blockchain network for consensus includes:

[0140] Obtain the information of the advance payment applicant corresponding to the information of the advance payment mortgage applicant, and obtain the information of the first associated advance payment institution associated with the information of the advance payment applicant;

[0141] Based on the first associated pre-support organization information, multiple target pre-support organization nodes are identified among multiple pre-support organization nodes;

[0142] The block data is sent to the target pre-support institution node for consensus.

[0143] In this implementation, the information of the applicant for advance payment can be related information of the individual or entity applying for advance payment, such as the applicant's basic information, such as identity information, financial status, credit record, etc. This information is used to assess the applicant's eligibility for advance payment and repayment ability.

[0144] The first associated advance payment institution information can refer to the information of financial institutions directly associated with the advance payment transaction in the blockchain loan process. This information is key data for identifying and confirming which financial institutions are the providers of loan funds. In this embodiment of the disclosure, the first associated advance payment institution information is associated with the advance payment application information. It can be understood that individuals or entities applying for advance payments can pre-bind financial institutions that provide advance payment services, that is, only the bound financial institutions provide funds.

[0145] The advance payment institution node refers to a node of a financial institution participating in an advance payment transaction within a pre-defined blockchain network. These nodes are responsible for processing transactions related to advance payments and reaching consensus on the blockchain to ensure the legality and validity of the transactions. Multiple advance payment institution nodes can be different nodes of different financial institutions providing advance payment services participating in the blockchain. The target advance payment institution node can be the node corresponding to the financial institution indicated by the first associated advance payment institution information among multiple advance payment institution nodes; that is, the node of the financial institution bound to the individual or entity applying for advance payment is identified as the target advance payment institution node. It is understood that the individual or entity applying for advance payment can only conduct transaction services with the bound financial institution. That is, other nodes besides the target advance payment institution node do not need to retain the corresponding transaction data of the individual or entity applying for advance payment. They can only select the target advance payment institution node in the pre-defined blockchain network to reach consensus on block data. By limiting the scope of nodes participating in consensus, the efficiency of the consensus process can be improved, resource waste can be reduced, and customized consensus services can be provided for specific financial transactions.

[0146] In one implementation, the process of consensus-building among target pre-support organization nodes on block data includes the following steps:

[0147] Based on the relationships contained in the block data, search for the information of the second associated pre-payment institution in the historical block data that is related to the information of the resource pre-payment mortgage object;

[0148] Based on the information of the second associated pre-payment agency, locate the associated historical resource processing events;

[0149] Conflict detection is performed on block data based on the event status of historical resource processing events to obtain consensus results.

[0150] In this implementation, the second associated pre-payment institution information can be information about other financial institutions in the blockchain network that have a direct or indirect relationship with the specific resource pre-payment collateral information. This information may include, but is not limited to, the financial institution's identifier, account details, and historical transaction records. Based on the relationships in the block data, the resource pre-payment collateral information in the relationships can be used as the specific resource pre-payment collateral information. Then, information about pre-payment institutions that have conducted transactions based on this specific resource pre-payment collateral information can be found in the blockchain and used as the second associated pre-payment institution information.

[0151] In blockchain technology, historical resource processing events refer to all past events and transaction records related to resource processing that are recorded on the blockchain. These events may include, but are not limited to, fund transfers, asset transactions, and contract executions. Historical resource processing events can also be understood as transaction events between the second-related advance payment structure corresponding to the second-related advance payment institution information and the individual or entity applying for advance payment.

[0152] Event states refer to state information related to specific transactions or smart contract interactions. This information reflects the current state of events occurring on the blockchain. These state changes can be updates to account balances, modifications to data in smart contracts, or the execution result of a specific business logic. This disclosure embodiment can determine the consensus result based on whether the resource processing event corresponding to the resource processing event information in the current block data conflicts with historical resource processing events, such as double-spending or reuse of collateral. Conflict detection ensures blockchain consistency and prevents problems such as double-spending.

[0153] In one implementation, conflict detection is performed on block data based on the event status of historical resource processing events to obtain a consensus result, including:

[0154] When there are unfinished target historical resource processing events in the historical resource processing events, the conflict detection result is determined to be a conflict.

[0155] If there are no unfinished historical resource processing events in the historical resource processing events, the conflict detection result is determined to be no conflict.

[0156] The consensus result is determined based on the conflict detection results.

[0157] In this implementation, the target historical resource processing event can be a historical resource processing event in which the current pre-payment institution is still conducting transactions based on the resource pre-payment collateral object. This historical resource processing event is not yet completed and may conflict with transactions in the current block data. For example, if an asset has been used or locked in a previous transaction, but is reused in the new block data, this will be identified as a conflict.

[0158] If all relevant historical resource processing events have been completed and there are no pending events, then it can be considered that there is no conflict with the current block data. It is understandable that when the event status of a historical resource processing event is "funds settled," it indicates that the historical resource processing event has ended and does not affect transactions in the current resource processing event; that is, the conflict detection is successful.

[0159] If the conflict detection result indicates a conflict exists, the current block may not be accepted, and the consensus result will be consensus failure. If the conflict detection result indicates no conflict exists, the current block data can be considered acceptable, and the consensus result will be consensus passed.

[0160] Step 204: Receive the consensus result returned by the preset blockchain network, and determine the detection result corresponding to the resource processing event detection request based on the consensus result.

[0161] The detection result can indicate whether the resource processing event conflicts with data from a pre-defined blockchain network. Upon receiving the consensus result from the pre-defined blockchain network, it can determine whether the resource pre-sale collateral has been recorded on the blockchain, and whether the related resource processing event information recorded on the blockchain matches the resource processing event information in the block data. If the consensus result shows that the block data has been verified by the consensus nodes, the detection request is considered successful. Conversely, if the consensus result indicates a conflict or failure to reach consensus, the detection result is considered unsuccessful, requiring further investigation or processing.

[0162] In one implementation, the consensus result returned by a preset blockchain network is received, and the detection result corresponding to the resource processing event detection request is determined based on the consensus result, including:

[0163] Receive multiple consensus results returned by multiple consensus nodes;

[0164] Extract conflict detection results from each consensus result to obtain multiple conflict detection results;

[0165] When there is a target conflict detection result indicating that the conflict detection is unqualified among multiple conflict detection results, the detection result corresponding to the resource processing event detection request is determined to be unqualified.

[0166] In this implementation, each consensus node processes the block data and generates a consensus result, thus establishing a one-to-one correspondence between consensus nodes and consensus results. The consensus result generated by each consensus node can be transmitted to nodes broadcasting block data via a pre-defined blockchain network.

[0167] Each consensus result can be obtained by consensus nodes performing conflict detection on block data based on resource processing relationships in historical block data. That is, each consensus result can include a conflict detection result, and multiple conflict detection results can be determined based on multiple consensus nodes.

[0168] A target conflict detection result can be a result indicating a failed conflict detection among multiple conflict detection results. This target conflict detection result can represent an event in the historical block data stored by the consensus node where the conflict detection occurred that conflicts with the current resource processing event, potentially leading to duplicate transactions. Therefore, the detection result can be determined as a failed detection based on the transaction conflict. It is understood that if at least one target conflict detection result appears among multiple conflict detection results, the detection result corresponding to the resource processing event detection request is considered a failed detection.

[0169] In one implementation, after determining that the detection result corresponding to the resource processing event detection request is a detection failure, the method further includes:

[0170] Generate feedback information indicating that the detection failed;

[0171] Send feedback information to the pre-payment agency corresponding to the pre-payment agency information.

[0172] In this embodiment, the feedback message can be a message indicating the detection result of a resource processing event detection request. In this disclosure embodiment, it can be a message indicating a failed detection, generated when the detection fails. The feedback information can explain the reason for the failed detection, including specific conflicting transactions, rule violations, or any other factors leading to the failure. The information can be written in a format understandable to the pre-paying institution, such as following specific encoding rules or data structures, and the feedback message can be sent to the corresponding pre-paying institution. The sending method can use protocols such as Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), or messaging systems specific to blockchain networks. Timely communication of detection results to pre-paying institutions ensures real-time information updates and avoids decision-making delays due to information lag.

[0173] In one implementation, after extracting a conflict detection result from each consensus result to obtain multiple conflict detection results, the method further includes:

[0174] When there is no target conflict detection result indicating that the conflict detection is unqualified among multiple conflict detection results, the detection result corresponding to the resource processing event detection request is determined to be qualified.

[0175] Add block data to the local blockchain;

[0176] The block data is sent to a pre-defined blockchain network for blockchain updates.

[0177] In this implementation, when no target conflict detection result indicating a failed conflict detection is found among multiple conflict detection results, it means that all transactions have passed the detection, and no consensus node has a transaction conflict. In this case, the detection result corresponding to the resource processing event detection request can be determined as a successful detection.

[0178] A local blockchain can be a copy of the blockchain information stored on the local storage device of a blockchain node. When a node adds this block data to its locally stored blockchain data, it signifies that the block data has been formally accepted and become part of the blockchain.

[0179] After a block of data is added to the local blockchain, the current node can broadcast it to the entire pre-defined blockchain network. Other nodes in the pre-defined blockchain network can then update their stored blockchain data, maintaining data consistency across the entire network. Upon receiving the broadcast block, other nodes in the pre-defined blockchain network can perform consensus processing again to ensure the block's legitimacy. If consensus is successful, these nodes can add the block to their own stored blockchains. Each node is responsible for verifying and maintaining the integrity of the blockchain. In this way, the blockchain network can resist fraud and tampering, maintaining data consistency and immutability.

[0180] In one implementation, after adding block data to the local blockchain, the method further includes:

[0181] Obtain the settlement message for the resource prepayment mortgage object corresponding to the information of the resource prepayment mortgage object;

[0182] Update the resource prepayment collateral object information according to the settlement message, and construct settlement block data based on the updated resource prepayment collateral object information and resource processing event information. The settlement block data includes the association between the updated resource prepayment collateral object information and resource processing event information.

[0183] Send the settlement block data to the preset blockchain network.

[0184] In this embodiment, the settlement message can be generated based on each processing stage of the resource prepayment collateral object. In this embodiment of the disclosure, for resource prepayment collateral objects based on smart contracts, the settlement message can be the settlement of the resource prepayment collateral object, such as the contract terms being met and executed. For example, it can be that the conditions for goods delivery or service provision have been met.

[0185] Settlement block data can be from a block following the block containing the settlement block data, or it can be from a block several blocks later. This settlement block data can store information about resource pre-payment collateral objects. This information is updated based on settlement messages, meaning the transaction status of the resource pre-payment collateral object information can be updated according to the instructions in the settlement message. The settlement block data can also store the correlation between the updated resource pre-payment collateral object information and resource processing event information. This correlation can be traced back to the block where the resource pre-payment collateral object was last updated, indicating that the update was performed on the resource pre-payment collateral object information in that block.

[0186] Settlement block data can be broadcast to consensus nodes within the blockchain network via a pre-defined blockchain network. These nodes then process the data and update the local blockchain upon successful consensus. Additionally, the data can be broadcast to consensus nodes via the pre-defined blockchain network for further updates. In other words, the latest information about resource pre-payment collateral on the pre-defined blockchain network represents the updated resource pre-payment collateral information in the settlement block data. Based on this updated information, when the status of a resource processing event changes (e.g., when funds are settled), the settlement record can be saved on the blockchain. Settlement block data can store settlement-related information as new resource processing event information. In this case, the relationships within the settlement block data can be traced back to the settlement block data, allowing for timely determination of the completion status of resource pre-payment collateral. Furthermore, the relationships within the settlement block data can also be traced back to the completion status of resource pre-payment collateral in the initial block. Correspondingly, the relationships within the settlement block data can also be traced back to the event status of resource processing events within the settlement block data, which will not be elaborated upon here. This approach ensures the updating and synchronization of blockchain data, and also enhances the security and reliability of the blockchain network by building and broadcasting settlement block data.

[0187] The resource processing event detection method provided in this embodiment includes: obtaining a resource processing event detection request, the resource processing event detection request including resource processing event information to be detected, the resource processing event information including resource pre-payment collateral object information and pre-payment institution information; constructing block data based on the resource pre-payment collateral object information and resource processing event information, the block data including the association relationship between the pre-payment collateral object information and the resource processing event information; sending the block data to a preset blockchain network for consensus processing, the preset blockchain network including multiple historical block data, the historical block data containing resource processing relationships between multiple resource pre-payment collateral objects and multiple resource processing events, consensus nodes in the preset blockchain network performing conflict detection on the block data based on the resource processing relationships to obtain a consensus result, the consensus nodes including at least the pre-payment institution node corresponding to the pre-payment institution information; receiving the consensus result returned by the preset blockchain network, and determining the detection result corresponding to the resource processing event detection request based on the consensus result.

[0188] This method generates block data by analyzing the pre-payment collateral information, resource processing event information, and the relationship between the two contained in the resource processing event, and uploads the block data to the blockchain for consensus. During the consensus process, each consensus node can perform conflict detection on the relationship based on the historical resource processing event information stored on the blockchain to avoid conflicts between the pre-payment collateral information and the resource processing event information, thereby ensuring the security of the resource processing event.

[0189] This disclosure provides a detailed description of the embodiments in conjunction with specific application scenarios.

[0190] like Figure 4 The diagram shown is another flowchart illustrating the resource processing event detection method provided in this disclosure. This embodiment will use a financial financing scenario as an example to detail the resource processing event detection method, applying it to a consortium blockchain. This consortium blockchain includes borrower nodes, loan platform nodes, and lender nodes, with the lender nodes comprising multiple consensus nodes. The method specifically includes the following steps:

[0191] Step 401: The loan platform node obtains the financing event detection request.

[0192] Loan platform nodes are nodes within a blockchain network responsible for handling loan-related operations and transactions. They receive loan-related transaction requests, such as borrowing and repayment, and verify the validity of these requests. They are also responsible for executing smart contracts, which automatically handle loan terms and conditions, such as automatically calculating interest and developing repayment plans. Borrowing nodes can initiate financing applications on loan platform nodes. Based on the borrower's application, the loan platform node deploys a smart contract containing the loan terms and conditions, such as interest rates, repayment periods, and collateral requirements. Once the smart contract is approved, a corresponding order is generated and displayed on the loan platform.

[0193] A financing event detection request can be a request from a lender to detect financing events corresponding to orders selected as financing objects on a lending platform. Alternatively, it can be understood that there are multiple orders on the lending platform, and the lender can select any number of orders as financing objects and generate corresponding promissory notes. These promissory notes can include the lender's institution information, and the lending platform node can detect whether there is only one promissory note for that order in the consortium blockchain. This embodiment of the disclosure uses any one of the selected orders as the description object.

[0194] Step 402: The loan platform node determines the loan receipt identifier and the loan receipt block pointer based on the loan receipt data, and determines the order identifier and the order block pointer based on the order data.

[0195] Loan agreement data can be a data structure that records customer loan information and loan agreement status within a loan agreement generated by the lender for an order. Loan agreement data can include key fields such as loan agreement identifier, customer information, lending institution information, loan amount, interest rate, loan date, maturity date, and the current status of the loan agreement. The loan agreement identifier serves as a unique identifier for each loan agreement. Customer information identifies the borrower, associating loan information with the correct customer. Lending institution information indicates the structure of the financing funds. The loan amount and interest rate indicate the cost of the loan and the repayment amount. The loan date and maturity date indicate the loan term and repayment timeframe. The loan agreement status reflects the loan's execution status, such as whether repayment has been made or whether it is overdue.

[0196] The IOU block pointer can be the block number of the IOU data in the historical blocks when it was last updated. That is, by using this number, the block of the latest IOU data in the historical blocks can be found and the latest IOU data can be identified.

[0197] Order data can be a series of information related to a loan request recorded on a lending platform, including order identifier, customer information, loan amount, repayment plan, and order status. The order identifier is used to identify and manage each order. Customer information includes basic customer information such as name, contact information, and address. The loan amount refers to the total amount of the loan applied for by the customer. The loan term includes the loan start date and end date. The repayment plan includes the amount and date of each repayment period. Order status reflects the current status of the order, such as approved, pending approval, canceled, or completed.

[0198] The order block pointer can be the block number of the last updated order data in the historical blocks. That is, based on this number, the block of the latest order data in the historical blocks can be found and the latest order data can be identified.

[0199] Step 403: The loan platform node constructs the block to be uploaded to the blockchain based on the loan receipt identifier, the loan receipt block pointer, the order identifier, and the order block pointer.

[0200] A block to be added to the blockchain refers to a block in a blockchain network that is ready to be added to the blockchain, containing a series of transaction records or other data. In this embodiment of the disclosure, the block to be added to the blockchain can record the loan receipt data, as well as the loan receipt identifier, the loan receipt block pointer, the order identifier, and the order block pointer. It is understood that the loan receipt identifier and the loan receipt block pointer in the block to be added to the blockchain have a corresponding relationship, the order identifier and the order block pointer have a corresponding relationship, and the loan receipt identifier and the order identifier have a corresponding relationship. Based on the loan receipt identifier, the corresponding block can be traced back according to the order block pointer, that is, it can be determined which order the loan receipt pertains to.

[0201] The data structure of blocks to be added to the blockchain can refer to the Unspent Transaction Outputs (UTXO) model adopted by the Virtual Resource Blockchain. In the Virtual Resource Network, the basic unit of a transaction is a UTXO. Each transaction contains one or more inputs and one or more outputs. Inputs point to the outputs of the previous transaction, while outputs create new UTXOs. Please refer to [link to relevant documentation]. Figure 5The diagram illustrating the UTXO structure, using Block 1 as an example, shows a new UTXO of 50.0 virtual coins created through a Coinbase (CB) transaction. This is a reward for resource miners, and there are no inputs as they are newly generated. Subsequently, in Block 2, this 50.0 virtual coin UTXO is used as input, and the transaction produces two new outputs: 8.70 virtual coins and 41.3 virtual coins, which can be used for payment and change, respectively. This pattern continues in Block 3, where the two outputs of Block 2 are used as inputs to construct a new transaction, producing a new UTXO of 58.7 virtual coins. In Block 4, the transaction becomes further complex, combining the 58.7 virtual coin output from Block 3 with the unused 41.3 virtual coin output from Block 2 to form two new outputs: 25.0 virtual coins and 66.3 virtual coins. This process not only demonstrates how UTXOs are consumed and recreated but also reflects the continuity and liquidity of virtual currency transactions. The core of the UTXO model lies in its irreversibility. Once a transaction is confirmed and added to the blockchain, the input UTXO is marked as spent, and the new output becomes a new UTXO, waiting to be used by future transactions.

[0202] In the UTXO model, when a UTXO is used as input to a transaction, it is consumed, generating a new UTXO as output. This process is traceable because each UTXO is associated with a specific transaction and block. Based on this characteristic, the order and loan data structures in the data structure of the block to be added to the blockchain can be traced back to the latest data update through block pointers, ensuring data traceability and integrity. This data structure can be referenced... Figure 6 As shown, taking the association structure of orders and IOUs as an example, this association structure illustrates how orders and IOUs are linked on the blockchain. The association structure includes an order identifier, an order block pointer, an IOU identifier, and an IOU block pointer. The order identifier is a unique identifier for the seller's sales order on the e-commerce platform within the blockchain. Each order generates a unique order identifier for identification and referencing on the blockchain. The order block pointer refers to the block number where the latest update of the order data corresponding to the order identifier is located. This pointer helps determine the precise location of the order data on the blockchain, facilitating traceability and verification. The IOU identifier is the unique identifier of the lender's IOU on the blockchain. Similar to the order identifier, the IOU identifier ensures that each IOU can be uniquely identified on the blockchain. The IOU block pointer refers to the block number where the latest update of the IOU data corresponding to the IOU identifier is located. This pointer is also used to locate the IOU data on the blockchain, ensuring data traceability.

[0203] Step 404: The loan platform node sends the block to be added to the blockchain to the consortium blockchain.

[0204] A consortium blockchain is a blockchain technology that lies between public and private blockchains, primarily used for collaboration and data sharing among specific organizations. In the financial sector, consortium blockchains are widely used in supply chain finance service platforms. For example, banks use blockchain technology to build supply chain finance service platforms aimed at providing financing services to suppliers and distributors across the industry chain. This platform achieves transparency and efficiency in fund flows by integrating order data and loan data. In a consortium blockchain, each transaction requires consensus among its members to form a block. Therefore, the blocks to be added to the blockchain by the loan platform nodes need to be verified by the consortium blockchain members; that is, the consortium blockchain performs consensus processing on the blocks to be added to the blockchain.

[0205] Step 405: The consensus node searches for the target IOU identifier in the historical blocks that points to the order data, performs consensus processing on the IOU identifier in the block to be added to the chain, and obtains the consensus result.

[0206] Consensus nodes can be nodes that maintain the operation of the blockchain network and ensure data consistency. In this embodiment, they can be lending nodes where various lending institutions that issue financing funds are located, including lending institutions indicated by the lending institution information. Consensus nodes can also include borrowing nodes. Borrowing nodes can be pre-bound to consensus nodes, meaning they only apply for financing to the bound consensus nodes. Consequently, only the bound consensus nodes will generate IOUs based on the orders and record them on the blockchain. Therefore, when the block to be uploaded to the blockchain corresponding to the borrowing node reaches consensus on the consortium blockchain, consensus does not need to be initiated with all nodes in the consortium blockchain; only the bound consensus node can receive the block to be uploaded and perform consensus processing.

[0207] Historical blocks can be blockchain blocks stored by each consensus node itself. They can be the same historical blocks as other consensus nodes, or they can include historical blocks that other consensus nodes do not have. A historical block is also a data structure including a loan agreement identifier, a loan agreement block pointer, an order identifier, and an order block pointer. A consensus node can query from the historical blocks the block that is the same as the block pointed to by the order block in the block to be uploaded to the blockchain. Based on the order block pointers in other historical blocks, it can query the target loan agreement data in the latest order status block. This target loan agreement data is then compared with the loan agreement data in the block to be uploaded to the blockchain for conflict detection. This conflict detection can check whether the target loan agreement identifier in the target loan agreement data matches the loan agreement identifier in the loan agreement data in the block to be uploaded to the blockchain, or it can check whether the target loan agreement identifier and target lending institution information in the target loan agreement data match the loan agreement identifier and lending institution information in the loan agreement data in the block to be uploaded to the blockchain. If they do not match, the conflict detection is considered to have failed, potentially indicating a problem of multiple parties financing a single order, and the consensus result is a failure. If there is agreement, the conflict detection is considered passed, the order is financed by only one lending institution, and the consensus result is considered passed.

[0208] Furthermore, when different target IOUs based on the same order are found in other nodes, the current status of the target IOU can be checked. If the current status of the target IOU is "funds settled," it means that the financing corresponding to the target IOU has ended and does not affect the current financing; the conflict detection result is "detection passed." Conversely, if the current status of the target IOU is "incomplete," it means that the financing corresponding to the target IOU still exists and conflicts with the current financing; the conflict detection result is "detection failed."

[0209] Step 406: The consensus node sends the consensus result to the consortium blockchain, which then sends it to the lending platform node.

[0210] A consensus node generates a consensus result, indicating whether it has accepted the block to be added to the blockchain. This result can be encapsulated as a message or data packet for transmission over the network. The data packet may contain the block's hash, transaction details, timestamp, and other necessary metadata. The consensus node can send the consensus result to other nodes in the consortium blockchain network, including lending platform nodes. Within a consortium blockchain, this communication is restricted; only authorized nodes can receive and process this information. Upon receiving the consensus result, the lending platform node can verify it to ensure the integrity and accuracy of the information. This may include checking the message signature, hash value, etc., to ensure the data has not been tampered with during transmission.

[0211] Step 407: The loan platform node determines the detection result of the financing event detection request based on the consensus result.

[0212] The detection result can indicate whether the financing event conflicts with historical block data on the consortium blockchain. Upon receiving the consensus result from the consortium blockchain, if the consensus result shows that the block data has been verified by the consensus nodes, the detection request can be considered successful. Conversely, if the consensus result indicates a conflict or failure to reach consensus, the detection result is considered a failure, requiring further investigation or processing. It is understandable that when the consensus result is a failure, the order pointed to in the block to be uploaded to the blockchain has already been recorded, and the relevant target loan data recorded on the blockchain is consistent with the loan data in the block to be uploaded.

[0213] The consensus results received by the loan platform node can be generated by multiple consensus nodes. That is, the loan platform node determines the detection result based on multiple consensus results. If any consensus result indicates that the detection has failed, the target loan in the block to be uploaded to the chain may conflict with the target loan in the consensus node corresponding to that consensus result, which may result in duplicate transactions. The detection result can be directly determined as a failure.

[0214] Step 408: When the detection result is "detection failed", the loan platform node notifies the lender that the detection failed.

[0215] Loan platform nodes can analyze the consensus results from the consortium blockchain. Once a failure is confirmed—meaning the financing event failed to pass the blockchain network's consensus verification or there are other issues that disqualify the loan—the loan platform node can send a notification to the lending institution via email, SMS, or the platform's messaging system, clearly informing them that the financing event's verification request failed. The notification can explain the specific reasons for the failure, such as unmet smart contract conditions, discrepancies between the loan agreement identifier and order data, or insufficient node confirmation for the transaction. This allows the lending institution to understand the cause of the failure and take appropriate remedial measures. Simultaneously, the loan platform node can also update the loan application status in its internal system, marking it as "detection failed."

[0216] Step 409: When the test result is "passed", the loan platform node will update the block to be uploaded to the consortium blockchain.

[0217] Once the lending platform nodes receive the consensus result from the consensus nodes and are aware that the test has passed, they can update the block to be added to the consortium blockchain. The lending platform nodes can then formally write key information contained in the block, such as transaction records, loan identifiers, and order identifiers, into the consortium blockchain. If the block contains smart contracts, the nodes will also execute these contracts, which may involve automatically disbursing loans or transferring funds.

[0218] Once a block is successfully added to the blockchain, the lending platform node can confirm that the transaction has been officially recorded and ensure that the new block is accepted and recognized by other nodes in the consortium blockchain. Simultaneously, the platform node will notify all relevant parties, including borrowers and lenders, that their transaction has been successfully recorded on the blockchain. This notification can be delivered through various means, including the platform's messaging system, email, or SMS. Furthermore, the lending platform node can also update its internal business records, marking the loan status as "disbursed" or "completed," and synchronously updating relevant financial and compliance records.

[0219] In one example, the entire process from order recording on the blockchain to IOU generation, IOU information updating, order settlement, and IOU clearance can trigger on-chain blockchain updates. Please refer to [link to relevant documentation]. Figure 7 The block tracing diagram shown is as follows:

[0220] The block where an order is first recorded on the blockchain can be called block C0. In block C0, order x is recorded on the blockchain for the first time. At this point, the order data is stored, and an association structure is created. This association structure only records the order identifier; the block pointers for both the order and the IOU are empty, and the IOU has not yet been generated.

[0221] The block where an order participates in financing can be called block C1. Block C1 can be the block following block C0, or it can be a block several blocks later. The lending institution selects order x to participate in the financing activity and generates the corresponding loan document y. At this time, while block C2 stores the loan document data, the associated structure records the order identifier and loan document identifier, and the order block pointer is updated to C0, that is, the block where the order was first added to the chain. If the order status or data changes during this period, the order block pointer will be updated to the block with the most recent change.

[0222] Over time, loan interest accumulates. Regularly updating interest calculation information ensures the accuracy of interest calculation and reflects the actual amount owed by the borrower. Loan agreements can be updated with interest calculation information periodically. Taking one update as an example, the block uploaded to the blockchain during this update can be called C2. The loan agreement data is updated, and simultaneously, the associated loan agreement block points to the updated C1, which is the block where the loan agreement data was most recently updated.

[0223] Order settlement occurs when a buyer purchases goods on an e-commerce platform and confirms receipt, marking the completion of the order transaction. The block uploaded to the blockchain during order settlement is called block C3, and the order status in the order data is updated to "settled." For related order structures, the block still points to C0, indicating that the order data remained unchanged before block C3. The promissory note block is updated to C2, the block where the promissory note interest information was last updated.

[0224] After order settlement, the repayment of the IOU can be triggered. The block on the blockchain when the IOU is settled can be called block C4. In block C4, the IOU status is updated to settled. The order block in the associated structure is updated to C3, which is the last block where the order was modified. The IOU block still points to C2, because C2 is the last block to update the IOU data before the IOU is settled.

[0225] Based on the block tracing diagram, when an order is simultaneously marked as a financing target by different lending institutions and generates loan receipt data, each institution creates the receipt according to its own business logic and data verification rules. This leads to different loan receipt data even for the same order, with the receipt identifier and lending institution identifier being significantly different. When the lending institution uploads the generated loan receipt data to the blockchain, if block tracing based on the association structure reveals the same order in historical blocks of the consortium blockchain, and different loan receipt data exists (e.g., different receipt identifiers and lending institution identifiers), it can be determined that there is a problem of multiple financing for a single order, resulting in consensus failure.

[0226] For example, if an order has already been financed, and another lending institution, due to faulty block data updates or data verification issues in its business system, marks the order as collateral and generates its loan agreement data, other institutions' blockchain nodes will discover the "error" in the aforementioned associated data during consensus. Corresponding to the association structure in the diagram above, the order block, loan agreement identifier, and loan agreement block pointer are all different from the data in the block awaiting consensus, leading to consensus failure and the discovery of the problem. Once consensus fails, the relevant nodes will refuse to accept the block, and the lending institution can re-examine and correct its financing object before attempting to reach consensus again.

[0227] Description of apparatus and devices according to embodiments of this disclosure

[0228] It is understood that although the steps in the above flowcharts are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated in this embodiment, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the above flowcharts may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0229] It should be noted that in the various specific embodiments of this disclosure, when processing is required based on data related to the characteristics of the target object, such as target object attribute information or a set of attribute information, the permission or consent of the target object will be obtained first. Furthermore, the collection, use, and processing of this data will comply with the relevant laws, regulations, and standards of the relevant regions. In addition, when this application embodiment needs to obtain target object attribute information, it will obtain the target object's separate permission or consent through pop-ups or redirection to a confirmation page. Only after obtaining the target object's separate permission or consent will the necessary target object-related data for the normal operation of this application embodiment be obtained.

[0230] Figure 8 This is a schematic diagram of the structure of a resource processing event detection device 800 provided in an embodiment of the present disclosure.

[0231] The device includes:

[0232] The acquisition unit 801 is used to acquire a resource processing event detection request. The resource processing event detection request includes information on the resource processing event to be detected. The resource processing event information includes information on the resource prepayment collateral object and information on the prepayment institution.

[0233] Construction unit 802 is used to construct block data based on resource pre-payment mortgage object information and resource processing event information. The block data includes the association between resource pre-payment mortgage object information and resource processing event information.

[0234] The sending unit 803 is used to send block data to a preset blockchain network for consensus processing. The preset blockchain network includes multiple historical block data. The historical block data contains the resource processing relationship between multiple resource pre-payment collateral objects and multiple resource processing events. The consensus nodes in the preset blockchain network perform conflict detection on the block data according to the resource processing relationship to obtain the consensus result. The consensus nodes include at least the pre-payment institution node corresponding to the pre-payment institution information.

[0235] The receiving unit 804 is used to receive the consensus result returned by the preset blockchain network and determine the detection result corresponding to the resource processing event detection request based on the consensus result.

[0236] Optionally, in some embodiments, the building unit 802 includes:

[0237] The first construction subunit is used to construct the first data object based on the information of the resource pre-payment mortgage object;

[0238] The second construction subunit is used to construct a second data object based on resource processing event information;

[0239] The third construction subunit is used to construct a third data object based on the association between the resource pre-payment mortgage object information and the resource processing event information, and to construct block data based on the first data object, the second data object and the third data object.

[0240] Optionally, in some embodiments, the third building subunit includes:

[0241] The first acquisition module is used to acquire the object number corresponding to the resource prepayment mortgage object information and the event number corresponding to the resource processing event information.

[0242] The query module is used to query the block number corresponding to the resource prepayment mortgage object information in historical block data, and to query the block number corresponding to the resource processing event information.

[0243] The first construction module is used to construct a third data object based on the object number, event number, the block number pointed to by the object, and the block number pointed to by the event.

[0244] Optionally, in some embodiments, the third building subunit includes:

[0245] The second acquisition module is used to acquire the hash value of the target historical block data with the highest block height in the historical block data of the preset blockchain network, and obtain the parent hash;

[0246] The second building module is used to construct a block body based on the first data object, the second data object, and the third data object;

[0247] The third construction module is used to construct the block header based on the encoding information corresponding to the first data object, the second data object, and the third data object, as well as the parent hash, and to determine the block data based on the block body and the block header.

[0248] Optionally, in some embodiments, the transmitting unit 803 includes:

[0249] The first acquisition subunit is used to acquire the advance application object information corresponding to the resource advance mortgage object information, and to acquire the first associated advance institution information associated with the advance application object information;

[0250] The first determining subunit is used to determine multiple target pre-supporting organization nodes among multiple pre-supporting organization nodes based on the first associated pre-supporting organization information;

[0251] The first sending subunit is used to send block data to the target pre-support organization node for consensus.

[0252] Optionally, in some embodiments, the receiving unit 804 includes:

[0253] The receiving subunit is used to receive multiple consensus results returned by multiple consensus nodes;

[0254] Extract sub-units to extract conflict detection results from each consensus result, resulting in multiple conflict detection results;

[0255] The second determining subunit is used to determine the detection result corresponding to the resource processing event detection request as unqualified when there is a target conflict detection result indicating that the conflict detection is unqualified among multiple conflict detection results.

[0256] Optionally, in some embodiments, the receiving unit 804 further includes:

[0257] The generation sub-unit is used to generate feedback information indicating that the detection failed.

[0258] The second sending subunit is used to send feedback information to the pre-supporting organization corresponding to the pre-supporting organization information.

[0259] Optionally, in some embodiments, the receiving unit 804 further includes:

[0260] The third determining subunit is used to determine the detection result corresponding to the resource processing event detection request as qualified when there is no target conflict detection result indicating that the conflict detection is unqualified among multiple conflict detection results.

[0261] Add sub-units to add block data to the local blockchain;

[0262] The third sending subunit is used to send block data to a preset blockchain network for blockchain updates.

[0263] Optionally, in some embodiments, the receiving unit 804 yuan further includes:

[0264] The second acquisition subunit is used to acquire the settlement message for the settlement of the resource prepayment mortgage object corresponding to the information of the resource prepayment mortgage object;

[0265] The update subunit is used to update the resource prepayment collateral object information according to the settlement message, and to construct settlement block data based on the updated resource prepayment collateral object information and resource processing event information. The settlement block data includes the association between the updated resource prepayment collateral object information and resource processing event information.

[0266] The fourth sending subunit is used to send settlement block data to the preset blockchain network.

[0267] A third aspect of this disclosure provides a consensus apparatus for block data, comprising:

[0268] The first search unit is used to search for information on the second associated pre-payment institution that is associated with the information on the resource pre-payment mortgage object in historical block data based on the association relationships contained in the block data;

[0269] The second search unit is used to search for related historical resource processing events based on the information of the second associated pre-payment organization.

[0270] The conflict detection unit is used to perform conflict detection on block data based on the event status of historical resource processing events to obtain consensus results.

[0271] Optionally, in some embodiments, the collision detection unit includes:

[0272] The first determining subunit is used to determine that a conflict exists when there is an unfinished target historical resource processing event in the historical resource processing events.

[0273] The second determining subunit is used to determine that there is no conflict when there are no unfinished historical resource processing events in the historical resource processing events.

[0274] The third determining subunit is used to determine the consensus result based on the conflict detection result.

[0275] Reference Figure 9 , Figure 9 To implement the structural block diagram of the transaction generation node 120 of the resource processing event detection method of this embodiment, the transaction generation node 120 includes: a radio frequency (RF) circuit 910, a memory 915, an input unit 930, a display unit 940, a sensor 950, an audio circuit 960, a wireless fidelity (WiFi) module 970, a processor 980, and a power supply 990, etc. Those skilled in the art will understand that... Figure 9 The structure of transaction generation node 120 shown does not constitute a limitation on the mobile phone or computer, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0276] The RF circuit 910 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 980; in addition, it transmits uplink data to the base station.

[0277] The memory 915 can be used to store software programs and modules. The processor 980 executes various terminal functions and document editing by running the software programs and modules stored in the memory 915.

[0278] The input unit 930 can be used to receive input numeric or character information, and to generate key signal inputs related to the terminal's settings and function control. Specifically, the input unit 930 may include a touch panel 931 and other input devices 932.

[0279] The display unit 940 can be used to display input or provided information, as well as various menus of the terminal. The display unit 940 may include a display panel 941.

[0280] Audio circuitry 960, speaker 961, and microphone 962 provide an audio interface.

[0281] In this embodiment, the processor 980 included in the transaction generation node 120 can execute the resource processing event detection method of the previous embodiment.

[0282] The transaction generation node 120 in this embodiment includes, but is not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc.

[0283] Figure 10 This is a partial structural block diagram of a consensus node 110 for implementing the resource processing event detection method of this disclosure embodiment. The consensus node 110 can vary significantly due to different configurations or performance, and may include one or more central processing units (CPUs) 1022 (e.g., one or more processors) and storage devices 1032, and one or more storage media 1030 (e.g., one or more mass storage devices) for storing application programs 1042 or data 1044. The storage devices 1032 and storage media 1030 can be temporary or persistent storage. The program stored in the storage media 1030 may include one or more modules (not shown in the figure), each module including a series of instruction operations on the consensus node 110. Furthermore, the central processing unit 1022 may be configured to communicate with the storage media 1030 and execute the series of instruction operations in the storage media 1030 on the consensus node 110.

[0284] The consensus node 110 may also include one or more power supplies 1026, one or more wired or wireless network interfaces 1050, one or more input / output interfaces 1058, and / or one or more operating systems 1041, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0285] The central processing unit 1022 in consensus node 110 can be used to execute the resource processing event detection method of the present disclosure embodiments.

[0286] This disclosure also provides a storage medium for storing program code, which is used to execute the resource processing event detection method of the foregoing embodiments.

[0287] This disclosure also provides a computer program product comprising a computer program. A processor of an electronic device reads and executes the computer program, causing the electronic device to perform the resource processing event detection method described above.

[0288] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure and the foregoing drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “including,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatuses.

[0289] It should be understood that in this disclosure, "at least one item" means one or more, and "more than one" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0290] It should be understood that in the description of the embodiments of this disclosure, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0291] In the several embodiments provided in this disclosure, 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 a logical functional division, 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, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0292] 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.

[0293] Furthermore, the functional units in the various embodiments of this disclosure 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0294] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0295] It should also be understood that the various implementation methods provided in this disclosure can be combined arbitrarily to achieve different technical effects.

[0296] The above is a detailed description of the embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure.

Claims

1. A method for detecting resource processing events, characterized in that, include: Obtain a resource processing event detection request, the resource processing event detection request including information on the resource processing event to be detected, the resource processing event information including information on the resource prepayment collateral object and information on the prepayment institution; Block data is constructed based on the resource pre-payment mortgage object information and the resource processing event information, and the block data includes the association relationship between the resource pre-payment mortgage object information and the resource processing event information; The block data is sent to a preset blockchain network for consensus processing. The preset blockchain network includes multiple historical block data, which contains resource processing relationships between multiple resource pre-sale collateral objects and multiple resource processing events. The consensus nodes in the preset blockchain network perform conflict detection on the block data based on the resource processing relationships to obtain a consensus result. The consensus nodes include at least the pre-sale institution node corresponding to the pre-sale institution information. Receive the consensus result returned by the preset blockchain network, and determine the detection result corresponding to the resource processing event detection request based on the consensus result.

2. The method according to claim 1, characterized in that, The step of constructing block data based on the resource pre-payment collateral object information and the resource processing event information includes: A first data object is constructed based on the information of the resource pre-payment mortgage object; A second data object is constructed based on the resource processing event information; A third data object is constructed based on the association between the resource pre-payment mortgage object information and the resource processing event information, and block data is constructed based on the first data object, the second data object and the third data object.

3. The method according to claim 2, characterized in that, The step of constructing a third data object based on the association between the resource pre-payment mortgage object information and the resource processing event information includes: Obtain the object number corresponding to the resource prepayment mortgage object information and the event number corresponding to the resource processing event information; In the historical block data, query the block number corresponding to the resource pre-payment mortgage object information, and query the block number corresponding to the resource processing event information; A third data object is constructed based on the object number, the event number, the block number pointed to by the object, and the block number pointed to by the event.

4. The method according to claim 2, characterized in that, The step of constructing block data based on the first data object, the second data object, and the third data object includes: Obtain the hash value of the target historical block with the highest block height from the historical block data in the preset blockchain network to get the parent hash; A block body is constructed based on the first data object, the second data object, and the third data object; The block header is constructed based on the encoding information corresponding to the first data object, the second data object, and the third data object, as well as the parent hash, and the block data is determined based on the block body and the block header.

5. The method according to claim 1, characterized in that, Sending the block data to a preset blockchain network for consensus includes: Obtain the advance application object information corresponding to the resource advance mortgage object information, and obtain the first associated advance institution information associated with the advance application object information; Based on the first associated pre-support organization information, multiple target pre-support organization nodes are determined among the multiple pre-support organization nodes; The block data is sent to the target pre-support organization node for consensus.

6. The method according to claim 5, characterized in that, The process by which the target pre-support organization nodes reach consensus on the block data includes the following steps: Based on the relationships contained in the block data, search for the information of the second associated pre-payment institution that is associated with the information of the resource pre-payment mortgage object in the historical block data; Based on the information of the second associated pre-payment organization, locate the associated historical resource processing events; Based on the event status of the historical resource processing events, conflict detection is performed on the block data to obtain a consensus result.

7. The method according to claim 6, characterized in that, The process of performing conflict detection on the block data based on the event status of the historical resource processing events to obtain a consensus result includes: When there is an unfinished target historical resource processing event among the historical resource processing events, the conflict detection result is determined to be a conflict. When there are no unfinished historical resource processing events among the historical resource processing events, the conflict detection result is determined to be no conflict. The consensus result is determined based on the conflict detection results.

8. The method according to claim 1, characterized in that, The step of receiving the consensus result returned by the preset blockchain network and determining the detection result corresponding to the resource processing event detection request based on the consensus result includes: Receive multiple consensus results returned by multiple consensus nodes; Conflict detection results are extracted from each consensus result to obtain multiple conflict detection results; When there is a target conflict detection result indicating that the conflict detection is unqualified among the multiple conflict detection results, the detection result corresponding to the resource processing event detection request is determined to be unqualified.

9. The method according to claim 8, characterized in that, After determining that the detection result corresponding to the resource processing event detection request is a detection failure, the method further includes: Generate feedback information indicating that the detection failed; The feedback information is sent to the pre-payment institution corresponding to the pre-payment institution information.

10. The method according to claim 8, characterized in that, After extracting conflict detection results from each consensus result to obtain multiple conflict detection results, the method further includes: When there is no target conflict detection result indicating that the conflict detection is unqualified among the multiple conflict detection results, the detection result corresponding to the resource processing event detection request is determined to be qualified. Add the block data to the local blockchain; The block data is sent to the preset blockchain network for blockchain update.

11. The method according to claim 10, characterized in that, After adding the block data to the local blockchain, the method further includes: Obtain the settlement message indicating the settlement of the resource prepayment mortgage object corresponding to the resource prepayment mortgage object information; The resource prepayment collateral object information is updated according to the settlement message, and settlement block data is constructed based on the updated resource prepayment collateral object information and the resource processing event information. The settlement block data includes the association relationship between the updated resource prepayment collateral object information and the resource processing event information. The settlement block data is sent to the preset blockchain network.

12. A device for detecting resource processing events, characterized in that, include: The acquisition unit is used to acquire a resource processing event detection request, wherein the resource processing event detection request includes information on the resource processing event to be detected, and the resource processing event information includes information on the resource prepayment collateral object and information on the prepayment institution; A construction unit is configured to construct block data based on the resource pre-payment mortgage object information and the resource processing event information, wherein the block data includes the association relationship between the resource pre-payment mortgage object information and the resource processing event information; A sending unit is used to send the block data to a preset blockchain network for consensus processing. The preset blockchain network includes multiple historical block data, which contains resource processing relationships between multiple resource pre-sale collateral objects and multiple resource processing events. The consensus nodes in the preset blockchain network perform conflict detection on the block data according to the resource processing relationships to obtain a consensus result. The consensus nodes include at least the pre-sale institution node corresponding to the pre-sale institution information. The receiving unit is configured to receive the consensus result returned by the preset blockchain network and determine the detection result corresponding to the resource processing event detection request based on the consensus result.

13. A storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the resource processing event detection method according to any one of claims 1 to 11.

14. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the resource processing event detection method according to any one of claims 1 to 11.

15. A computer program product comprising a computer program that is read and executed by a processor of an electronic device, causing the electronic device to perform the resource processing event detection method according to any one of claims 1 to 11.

Images