System and method for matching demands in decentralized network

Abstract

The invention discloses an appeal matching system and method in a decentralized network. According to the system, the security and privacy protection of the matching system are remarkably improved through the distributed account book and the decentralized identity, and data tampering and leakage are prevented; an intelligent contract and a matching request optimization module are introduced, so that the matching efficiency and transparency are improved, and human intervention is reduced; a decentralized network architecture enhances the expandability and reliability of the system, supports high-concurrency processing and reduces the operation cost; user experience and credibility are improved through user feedback and a multi-verification mechanism, and malicious behaviors are reduced; a flexible recommendation and broadcast mechanism further expands the matching range and increases income sources. According to the invention, an efficient, reliable, safe and user-friendly solution is provided for matching demands in a decentralized network.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a demand matching system and method in a decentralized network. Background Art

[0002] Traditional centralized matching systems rely on a single central server or control center, which is prone to single-point failure risks. In centralized systems, all user data (including transaction requests and personal information) is stored on the central server, making it an easy target for hackers. The centralized matching process is controlled by a central organization, and users cannot directly view the detailed matching process and rules, resulting in a lack of transparency. As a result, users have low trust in the system. Users may worry that their requests will be treated unfairly or that their data will be tampered with.

[0003] While exchange matching systems utilize decentralized network technologies, their demands are often relatively simple, focusing on the high and low bids of both long and short parties, and are limited to high-frequency trading scenarios. Furthermore, some technologies, such as message-in-a-bottle, can be used for certain coupling mechanisms, but they are too arbitrary, lack effective protection against double-spending attacks, and can also pose risks such as duplicate user submissions. Matching requests cannot accommodate a diverse and broad range of demands, and optimization is impossible, resulting in users often receiving less than ideal satisfaction. It also makes it difficult for the community to properly anticipate and monitor user demands. Summary of the Invention

[0004] In order to solve the above technical problems, the present invention proposes a demand matching system and method in a decentralized network, which provides an efficient, reliable, secure and user-friendly solution for the matching needs in a decentralized network.

[0005] In order to achieve the above object, the technical solution of the present invention is as follows:

[0006] A demand matching system in a decentralized network, the system is implemented based on distributed ledger technology, and the distributed ledger supports decentralized identities of users, including:

[0007] Demand data receiving module: used to receive demand data from multiple users, wherein the demand data defines potential interaction or transaction needs between users;

[0008] Matching request generation module: used to generate a matching request based on the demand data, wherein the matching request includes the user's decentralized identity and description information of potential interaction or transaction needs between users;

[0009] Unique identification module: used to generate a unique identifier for each matching request and record it on the distributed ledger;

[0010] Timestamp and order verification module: used to add a timestamp to each matching request and record the order of matching requests on the distributed ledger;

[0011] Repeated request restriction module: used to restrict the same user from posting the same request data within a preset time interval;

[0012] Matching request status management module: used to set a status flag for each matching request and record the current status of the matching request. The status flags of matching requests include: pending, processed, unsuccessful, and withdrawn.

[0013] Matching request broadcast module: used to broadcast the matching request to one or more matching nodes in the decentralized network, and the matching nodes are used to match qualified users according to the matching request;

[0014] Matching result processing module: used to receive the matching results returned by the matching node and notify the relevant users of the matching results;

[0015] Consensus mechanism module: used to ensure that only one matching result is accepted through the distributed ledger consensus mechanism when multiple matching nodes process the same matching request simultaneously;

[0016] Priority mechanism module: used to select the highest priority matching result based on the timestamp or trust score of the matching node;

[0017] Matching result status management module: responsible for managing the status of each matching result. The status identification of matching results includes pending confirmation, accepted, and revoked. After the matching result is generated and before consensus is reached, it is in the pending confirmation state. After it passes the consensus mechanism, it is in the accepted state. The remaining matching results that do not pass the consensus mechanism are marked as revoked;

[0018] Notification mechanism module: used to notify other matching nodes to cancel matching results and update status;

[0019] User Matching Request Cancellation Module: This module is used to receive a user's request to cancel a matching request before the matching request status is processed. The matching request status is updated from pending to canceled. The timestamp and user ID of the cancellation operation are recorded in the distributed ledger. All matching nodes currently processing the matching request are notified to stop processing and update their status.

[0020] User feedback and reporting module: used to receive user feedback and reports on matching results. The system handles abnormal situations in a timely manner based on user feedback to prevent malicious behavior.

[0021] Preferably, a multiple verification module is also included, which is used to perform multiple verifications when the matching node processes the matching request. The multiple verifications include verifying the user's decentralized identity, the authenticity and legitimacy of the request data.

[0022] Preferably, the consensus mechanism includes PoW, PoS, and PBFT.

[0023] Preferably, it further includes a matching request optimization module, which is used to classify or prioritize the matching requests based on the interaction themes or conditions in the demand data.

[0024] Preferably, the matching node includes a smart contract module and a decentralized application module. The smart contract module includes one or more smart contracts, which automatically screen other qualified users according to preset matching rules; the decentralized application module includes one or more decentralized applications, which record matching requests and matching results through a distributed ledger to ensure the transparency and immutability of the matching process.

[0025] Preferably, it further includes a trust score generation module, which is used to generate a trust score for the matching node, and the trust score is updated based on the historical matching success rate, response time and user feedback of the matching node.

[0026] Preferably, it also includes a recommendation information generation module, which is used to generate relevant recommendation information or advertisements according to the interactive theme of the matchmaking request to expand the matchmaking scope or improve the matchmaking success rate.

[0027] Preferably, the demand data includes certification data and attribute data, wherein the certification data is used to verify the authenticity and legitimacy of the user's demand; and the attribute data is used to describe the user's preferences or demand characteristics.

[0028] Preferably, the matching request is broadcast to all matching nodes associated with the system, or only to matching nodes that have subscribed to receive matching requests.

[0029] Based on the above, the present invention further discloses a method for matching demands in a decentralized network. The method is implemented based on distributed ledger technology, and the distributed ledger supports decentralized identities of users, and includes the following steps:

[0030] receiving demand data from multiple users, wherein the demand data defines potential interaction or transaction needs between the users, and the same user is prohibited from posting the same demand data within a preset time interval;

[0031] Generate a matching request based on the demand data, wherein the matching request includes the user's decentralized identity and description information of potential interaction or transaction needs between users;

[0032] Generate a unique identifier for each matching request and record it on the distributed ledger; add a timestamp to each matching request and record the order of matching requests on the distributed ledger;

[0033] A status flag is set for each matching request to record the current processing status of the matching request. The status flags of matching requests include: pending, processed, unsuccessful, and withdrawn.

[0034] Broadcasting the matching request to one or more matching nodes in the decentralized network, which are used to match eligible users based on the matching request;

[0035] Receive the matching results returned by the matching node and notify the relevant users of the matching results;

[0036] When multiple matching nodes process the same matching request simultaneously, the matching result with the highest priority is selected based on the timestamp or the trust score of the matching node to ensure that only one matching result is accepted;

[0037] Responsible for managing the status of each matching result. The status of matching results includes pending confirmation, accepted, and revoked. After the matching result is generated and before consensus is reached, it is in the pending confirmation state. After it passes the consensus mechanism, it is in the accepted state. The remaining matching results that do not pass the consensus mechanism are marked as revoked. Notify other matching nodes to revoke the matching result and update the status.

[0038] Before a matching request reaches the processed status, if the user requests a cancellation, the matching request status is updated from pending to canceled. The cancellation operation timestamp and user ID are recorded in the distributed ledger, and all matching nodes currently processing the matching request are notified to stop processing and update their status.

[0039] Receive user feedback and reports on matching results, and promptly handle abnormal situations based on user feedback and reports to prevent malicious behavior;

[0040] When a matching node processes a matching request, it performs multiple verifications, including verifying the user's decentralized identity and the authenticity and legitimacy of the requested data.

[0041] Based on the above technical solution, the beneficial effects of the present invention are as follows: the present invention significantly improves the security and privacy protection of the matching system through distributed ledgers and decentralized identities (DIDs), preventing data tampering and leakage. The introduction of smart contracts and matching request optimization modules improves matching efficiency and transparency, and reduces human intervention. The decentralized network architecture enhances the scalability and reliability of the system, supports high-concurrency processing, and reduces operating costs. User feedback and multiple verification mechanisms improve user experience and trust, and reduce malicious behavior. Flexible recommendation and broadcast mechanisms further expand the scope of matching and increase revenue sources. Overall, this technology provides an efficient, reliable, secure, and user-friendly solution for matching needs in decentralized networks. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 The diagram is a structural diagram of a demand matching system in a decentralized network in one embodiment. DETAILED DESCRIPTION

[0043] The technical solutions in the embodiments of the present invention will be described clearly and completely below with reference to the accompanying drawings in the embodiments of the present invention.

[0044] like Figure 1 As shown, this embodiment provides a demand matching system in a decentralized network. The system is implemented based on distributed ledger technology. The distributed ledger supports the user's decentralized identity (DID), including:

[0045] Demand data receiving module: used to receive demand data from multiple users, wherein the demand data defines potential interaction or transaction needs between users;

[0046] Matching request generation module: used to generate a matching request based on the demand data, wherein the matching request includes the user's decentralized identity and description information of potential interaction or transaction needs between users;

[0047] Unique Identification Module: used to generate a unique identifier (UUID) for each matching request and record it on the distributed ledger to ensure the uniqueness and traceability of each matching request;

[0048] Timestamp and sequence verification module: used to add a timestamp to each matching request and record the order of matching requests on the distributed ledger to prevent the same user from repeatedly issuing the same matching request within a short period of time;

[0049] Repeated request restriction module: used to restrict the same user from posting the same request data within a preset time interval. The preset time interval can be adjusted according to the actual application scenario;

[0050] Matching request status management module: used to set a status identifier for each matching request and record the current status of the matching request. The status identifiers of the matching request include: pending, processed, unsuccessful, and revoked. The pending status indicates that the matching request has been received and recorded by the system, but has not yet been processed by any matching node; the processed status indicates that the matching request has been received and matched by the matching node, and a matching result has been generated; the unsuccessful status indicates that although the matching request has been processed by the matching node, no matching user that meets the conditions has been found, and the matching is unsuccessful; the revoked status indicates that the matching request has been revoked and no matching operation will be performed.

[0051] Matching request broadcast module: used to broadcast the matching request to one or more matching nodes in the decentralized network, and the matching nodes are used to match qualified users according to the matching request;

[0052] Matching result processing module: used to receive the matching results returned by the matching node and notify the relevant users of the matching results;

[0053] Consensus mechanism module: used to ensure that only one matching result is accepted through the distributed ledger consensus mechanism (consensus mechanisms include PoW, PoS, PBFT, etc.) when multiple matching nodes process the same matching request simultaneously;

[0054] Priority mechanism module: used to select the highest priority matching result based on the timestamp or trust score of the matching node;

[0055] Matching result status management module: responsible for managing the status of each matching result. The status identification of the matching result includes pending confirmation, accepted, and revoked. The matching result is in the pending confirmation state after it is generated and before consensus is reached. The status is accepted after it passes the consensus mechanism. The remaining matching results that do not pass the consensus mechanism are marked as revoked;

[0056] Notification mechanism module: used to notify other matching nodes to cancel matching results and update status;

[0057] User Matching Request Cancellation Module: This module is used to receive a user's request to cancel a matching request before the matching request status is processed. The matching request status is updated from pending to canceled. The cancellation operation timestamp and user ID are recorded in the distributed ledger to ensure the traceability of the cancellation operation. At the same time, all matching nodes that are processing the matching request are notified to stop processing and update the status.

[0058] User feedback and reporting module: used to receive user feedback and reports on matchmaking results. The system handles abnormal situations in a timely manner based on user feedback to prevent malicious behavior;

[0059] Multi-verification module: used to perform multiple verifications when the matching node processes the matching request. The multiple verifications include verifying the user's decentralized identity, the authenticity and legitimacy of the request data, etc.

[0060] In one embodiment, a demand matching system in a decentralized network further includes a matching request optimization module, which is configured to classify or prioritize the matching requests based on the interaction topics or conditions in the demand data to optimize matching efficiency.

[0061] Specifically, the interaction theme refers to the type of interaction or transaction that the user wishes to conduct, such as: buying and selling of goods (such as second-hand goods trading, digital goods trading, etc.), service exchange (such as housekeeping services, technical consulting, design services, etc.), cooperation needs (such as project cooperation, team building, resource sharing, etc.); social interaction (such as finding interest groups, event organization, etc.); conditions refer to the user's specific requirements for interaction or transaction, such as: price range (such as product price, service fee, etc.), time requirements (such as service time, delivery time, etc.), location requirements (such as transaction location, service location, etc.), quality standards (such as product quality, service quality, etc.), user preferences (such as brand preference, service type preference, etc.).

[0062] To optimize matching efficiency, the system categorizes matching requests based on interaction topics or conditions. Categorization helps matching nodes find matching users more quickly and reduces unnecessary computation and communication overhead. Here are some common categorization methods:

[0063] 1. Classify by interaction theme, such as commodity trading, service exchange, cooperation needs, and social interaction.

[0064] 2. Classification by conditions refers to further classification by conditions under the same subject classification, for example:

[0065] 1) Price range: Matching requests are divided into different subcategories based on price range, such as "low-priced goods", "medium-priced goods", and "high-priced goods";

[0066] 2) Time sensitivity: Matchmaking requests are categorized into “urgent needs,” “routine needs,” and “long-term needs” based on time requirements;

[0067] 3) Location scope: Matchmaking requests are categorized into “local demand,” “cross-regional demand,” and “global demand” based on location requirements;

[0068] 4) Quality Standard: Matchmaking requests are categorized into “high quality request,” “medium quality request,” and “low quality request” based on quality requirements.

[0069] Prioritization can help matching nodes prioritize more important requests when processing matching requests, thereby improving the overall efficiency of the system and user experience. The following are some priority sorting strategies:

[0070] 1. Sorting based on timestamp: Matching requests are sorted in the order of submission time, with requests submitted earlier being processed first;

[0071] 2. Sorting based on user reputation: Matchmaking requests are sorted based on the user's historical reputation score, with requests from users with high reputation being given priority;

[0072] 3. Sort by urgency: Sort requests based on the urgency specified by the user in the matchmaking request (e.g., "urgent," "routine," "not urgent");

[0073] 4. Sort by transaction value: Sort requests by the transaction amount or value involved in the matching request, with high-value requests being processed first;

[0074] 5. Sorting based on matching success rate: Requests are sorted based on their historical success rate (i.e., the matching success rate of similar requests in the past), with requests with higher success rates being prioritized.

[0075] 6. Comprehensive Priority Sorting: Taking into account multiple factors such as timestamp, user reputation, urgency of demand, transaction value, etc., the priority of each matching request is calculated through a weighted algorithm.

[0076] Example:

[0077] Assume that the system receives the following matching request:

[0078] 1. User A submits a product transaction request, hoping to purchase a used computer for no more than 1,000 yuan within one week.

[0079] 2. User B submits a service exchange request, hoping to find a domestic worker within three days.

[0080] 3. User C submitted a collaboration request, hoping to find a technical team to develop software together within one month.

[0081] Classification

[0082] User A's request is classified as "commodity transaction type".

[0083] User B's request is classified as "service exchange class".

[0084] User C's request is classified as "cooperation demand class".

[0085] Prioritization

[0086] Assume that the system adopts comprehensive priority sorting, and the weights are set as follows:

[0087] Timestamp weight: 30%

[0088] User reputation weight: 20%

[0089] Requirement urgency weight: 30%

[0090] Transaction value weight: 20%

[0091] User A's credit score is 80, the urgency of the demand is "regular", and the transaction value is 1,000 yuan.

[0092] User B's credit score is 90, the urgency of the demand is "urgent", and the transaction value is 500 yuan.

[0093] User C's credit score is 70, the urgency of the demand is "regular", and the transaction value is 5,000 yuan.

[0094] Calculation priority:

[0095] User A's priority = 0.3 × 1 + 0.2 × 0.8 + 0.3 × 0.5 + 0.2 × 1 = 0.71

[0096] User B's priority = 0.3 × 1 + 0.2 × 0.9 + 0.3 × 1 + 0.2 × 0.5 = 0.83

[0097] User C's priority = 0.3 × 1 + 0.2 × 0.7 + 0.3 × 0.5 + 0.2 × 5 = 1.11

[0098] According to the priority sorting, the matching node will first process the request of user C, followed by the request of user B, and finally the request of user A.

[0099] Through proper classification and prioritization, the matching system can more efficiently process matching requests, improving user experience and system efficiency. Classification can be based on interaction topics or conditions, while prioritization can comprehensively consider multiple factors such as timestamp, user reputation, urgency of the request, and transaction value. Furthermore, the matching request optimization module can consider using large-scale modeling techniques to assist in optimizing matching requests.

[0100] In one embodiment, a demand matching system in a decentralized network also provides specific settings for a matching node, which includes a smart contract module and a decentralized application module. The smart contract module includes one or more smart contracts, which automatically screen other qualified users according to preset matching rules; the decentralized application module includes one or more decentralized applications (DApps), which record matching requests and matching results through a distributed ledger to ensure the transparency and immutability of the matching process.

[0101] In one embodiment, a demand matching system in a decentralized network further includes a trust score generation module, which is configured to generate a trust score for the matching node. The trust score is updated based on the matching node's historical matching success rate, response time, and user feedback.

[0102] In one embodiment, a demand matching system in a decentralized network further includes a recommendation information generation module, which is configured to generate relevant recommendation information or advertisements based on the interactive theme of the matching request to expand the matching scope or improve the matching success rate.

[0103] In one embodiment, a demand matching system in a decentralized network also includes specific settings of demand data, which includes proof data and attribute data. The proof data is used to verify the authenticity and legitimacy of the user's demand; the attribute data is used to describe the user's preferences or demand characteristics.

[0104] In an embodiment, in a demand matching system in a decentralized network, a matching request is broadcast to all matching nodes associated with the system, or only to matching nodes that have subscribed to receive the matching request.

[0105] This embodiment proposes a method for matching demands in a decentralized network. The method is implemented based on distributed ledger technology. The distributed ledger supports decentralized identities of users and includes the following steps:

[0106] receiving demand data from multiple users, wherein the demand data defines potential interaction or transaction needs between the users, and the same user is prohibited from posting the same demand data within a preset time interval;

[0107] Generate a matching request based on the demand data, wherein the matching request includes the user's decentralized identity and description information of potential interaction or transaction needs between users;

[0108] Generate a unique identifier for each matching request and record it on the distributed ledger to ensure the uniqueness and traceability of each matching request; add a timestamp to each matching request and record the order of matching requests on the distributed ledger;

[0109] A status flag is set for each matching request to record the current processing status of the matching request. The status flags of matching requests include: pending, processed, unsuccessful, and withdrawn.

[0110] Broadcasting the matching request to one or more matching nodes in the decentralized network, which are used to match eligible users based on the matching request;

[0111] Receive the matching results returned by the matching node and notify the relevant users of the matching results;

[0112] When multiple matching nodes process the same matching request simultaneously, the matching result with the highest priority is selected based on the timestamp or the trust score of the matching node to ensure that only one matching result is accepted;

[0113] Responsible for managing the status of each matching result. The status of matching results includes pending confirmation, accepted, and revoked. After the matching result is generated and before consensus is reached, it is in the pending confirmation state. After it passes the consensus mechanism, it is in the accepted state. The remaining matching results that do not pass the consensus mechanism are marked as revoked. Notify other matching nodes to revoke the matching result and update the status.

[0114] Before a matching request reaches the processed status, if the user requests a cancellation, the matching request status is updated from pending to canceled. The cancellation operation timestamp and user ID are recorded in the distributed ledger, and all matching nodes currently processing the matching request are notified to stop processing and update their status.

[0115] Receive user feedback and reports on matching results, and promptly handle abnormal situations based on user feedback and reports to prevent malicious behavior;

[0116] When a matching node processes a matching request, it performs multiple verifications, including verifying the user's decentralized identity and the authenticity and legitimacy of the requested data.

[0117] It should be understood that, although the various steps in the above flow chart are shown in sequence as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be performed in other orders. Moreover, at least a portion of the steps in the above flow chart may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily performed at the same time, but can be performed at different times, and the execution order of these sub-steps or stages is not necessarily to be performed in sequence, but can be performed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0118] The foregoing description is merely a preferred embodiment of the disclosed system and method for matching requests in a decentralized network and is not intended to limit the scope of protection of the embodiments herein. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the embodiments herein shall be included within the scope of protection of the embodiments herein.

Claims

1. A demand matching system in a decentralized network, characterized by: The system is implemented based on distributed ledger technology, which supports decentralized identities of users, including: Demand data receiving module: used to receive demand data from multiple users, wherein the demand data defines potential interaction or transaction needs between users; Matching request generation module: used to generate a matching request based on the demand data, wherein the matching request includes the user's decentralized identity and description information of potential interaction or transaction needs between users; Unique identification module: used to generate a unique identifier for each matching request and record it on the distributed ledger; Timestamp and order verification module: used to add a timestamp to each matching request and record the order of matching requests on the distributed ledger; Repeated request restriction module: used to restrict the same user from posting the same request data within a preset time interval; Matching request status management module: used to set a status flag for each matching request and record the current status of the matching request. The status flags of matching requests include: pending, processed, unsuccessful, and withdrawn. Matching request broadcast module: used to broadcast the matching request to one or more matching nodes in the decentralized network, and the matching nodes are used to match qualified users according to the matching request; Matching result processing module: used to receive the matching results returned by the matching node and notify the relevant users of the matching results; Consensus mechanism module: used to ensure that only one matching result is accepted through the distributed ledger consensus mechanism when multiple matching nodes process the same matching request simultaneously; Priority mechanism module: used to select the highest priority matching result based on the timestamp or trust score of the matching node; Matching result status management module: responsible for managing the status of each matching result. The status identification of matching results includes pending confirmation, accepted, and revoked. After the matching result is generated and before consensus is reached, it is in the pending confirmation state. After it passes the consensus mechanism, it is in the accepted state. The remaining matching results that do not pass the consensus mechanism are marked as revoked; Notification mechanism module: used to notify other matching nodes to cancel matching results and update status; User Matching Request Cancellation Module: This module is used to receive a user's request to cancel a matching request before the matching request status is processed. The matching request status is updated from pending to canceled. The timestamp and user ID of the cancellation operation are recorded in the distributed ledger. All matching nodes currently processing the matching request are notified to stop processing and update their status. User feedback and reporting module: used to receive user feedback and reports on matching results. The system handles abnormal situations in a timely manner based on user feedback to prevent malicious behavior.

2. A demand matching system in a decentralized network according to claim 1, characterized in that: It also includes a multiple verification module, which is used to perform multiple verifications when the matching node processes the matching request. The multiple verifications include verifying the user's decentralized identity and the authenticity and legitimacy of the request data.

3. A demand matching system in a decentralized network according to claim 1, characterized in that: The consensus mechanisms include PoW, PoS, and PBFT.

4. A demand matching system in a decentralized network according to claim 1, characterized in that: It also includes a matching request optimization module, which is used to classify or prioritize the matching requests based on the interaction topics or conditions in the demand data.

5. A demand matching system in a decentralized network according to claim 1, characterized in that: The matching node includes a smart contract module and a decentralized application module. The smart contract module includes one or more smart contracts, which automatically screen other qualified users according to preset matching rules. The decentralized application module includes one or more decentralized applications, which record matching requests and matching results through a distributed ledger to ensure the transparency and immutability of the matching process.

6. A demand matching system in a decentralized network according to claim 1, characterized in that: The module also includes a trust score generation module, which is used to generate a trust score for the matching node. The trust score is updated based on the matching node's historical matching success rate, response time, and user feedback.

7. A demand matching system in a decentralized network according to claim 1, characterized in that: It also includes a recommendation information generation module, which is used to generate relevant recommendation information or advertisements according to the interactive theme of the matchmaking request to expand the matchmaking scope or improve the matchmaking success rate.

8. A demand matching system in a decentralized network according to claim 1, characterized in that: The demand data includes certification data and attribute data. The certification data is used to verify the authenticity and legitimacy of the user's demand; the attribute data is used to describe the user's preferences or demand characteristics.

9. A demand matching system in a decentralized network according to claim 1, characterized in that: The matching request is broadcast to all matching nodes associated with the system, or only to matching nodes that have subscribed to receive matching requests.

10. A demand matching method in a decentralized network, characterized in that: The method is implemented based on distributed ledger technology that supports decentralized identities of users and includes the following steps: receiving demand data from multiple users, wherein the demand data defines potential interaction or transaction needs between the users, and the same user is prohibited from posting the same demand data within a preset time interval; Generate a matching request based on the demand data, wherein the matching request includes the user's decentralized identity and description information of potential interaction or transaction needs between users; Generate a unique identifier for each matching request and record it on the distributed ledger; add a timestamp to each matching request and record the order of matching requests on the distributed ledger; A status flag is set for each matching request to record the current processing status of the matching request. The status flags of matching requests include: pending, processed, unsuccessful, and withdrawn. Broadcasting the matching request to one or more matching nodes in the decentralized network, which are used to match eligible users based on the matching request; Receive the matching results returned by the matching node and notify the relevant users of the matching results; When multiple matching nodes process the same matching request simultaneously, the matching result with the highest priority is selected based on the timestamp or the trust score of the matching node to ensure that only one matching result is accepted; Responsible for managing the status of each matching result. The status of matching results includes pending confirmation, accepted, and revoked. After the matching result is generated and before consensus is reached, it is in the pending confirmation state. After it passes the consensus mechanism, it is in the accepted state. The remaining matching results that do not pass the consensus mechanism are marked as revoked. Notify other matching nodes to revoke the matching result and update the status. Before a matching request reaches the processed status, if the user requests a cancellation, the matching request status is updated from pending to canceled. The cancellation operation timestamp and user ID are recorded in the distributed ledger, and all matching nodes currently processing the matching request are notified to stop processing and update their status. Receive user feedback and reports on matching results, and promptly handle abnormal situations based on user feedback and reports to prevent malicious behavior; When a matching node processes a matching request, it performs multiple verifications, including verifying the user's decentralized identity and the authenticity and legitimacy of the requested data.

Images