Data asset transaction three-level node platform design method of mimicry construction

Abstract

The invention relates to the field of data assets, in particular to a data asset transaction three-level node platform design method of a mimicry structure. The method comprises the following steps: S1, initializing a system, and registering an IP address and port information accessed by an external entity; s2, receiving a task request of the mimicry dispatcher, and selecting an executor to carry out task allocation; s3, returning the IP address of the selected executor to the mimicry dispatcher; s4, the mimicry dispatcher distributes the access request information to a specified executor; s5, the executor processes the access request of the mimicry dispatcher, and consistency voting is carried out; s6, the mimicry judgment gateway carries out consistency voting on the results of the multiple execution bodies; and S7, calling a corresponding interface to execute a task according to the type and the target of the request and the type of the micro-service. According to the method, diversified network attacks are defended by introducing cooperative work of a dynamic, heterogeneous and redundant mimicry defense architecture and a core function component, and the consistency of data processing and the high availability of the system are ensured.

Description

Technical Field

[0001] The present invention relates to the field of data assets, and in particular to a design method for a three-level node platform for data asset transactions with a mimetic structure. Background Art

[0002] The design method of the three-level node platform for data asset transactions based on mimicry defense aims to improve the security and reliability of data asset transactions. Through a dynamic, heterogeneous, and redundant mimicry defense mechanism, it controls the security vulnerabilities and consistency issues that may occur in the data transaction process, and realizes efficient data transaction protection with multi-executor parallel processing and consistency voting.

[0003] The existing three-level node platform for data asset trading usually finds it difficult to achieve all-round security protection when facing complex network attacks. In addition, due to the potential risks in the internal processing flow, it will lead to internal data processing inconsistency, increased risk of single point failure, and the inability to respond and protect in a timely and effective manner when encountering advanced persistent threats. Therefore, a design method for a three-level node platform for data asset trading with a mimetic structure is provided. Summary of the invention

[0004] The purpose of the present invention is to provide a method for designing a three-level node platform for data asset transactions with a mimetic structure, so as to solve the problems raised in the above background technology, that is, the potential risks in the internal processing flow will lead to inconsistency in internal data processing, increased risk of single point failure, and inability to respond and protect in a timely and effective manner when encountering advanced persistent threats.

[0005] To achieve the above object, the present invention provides a method for designing a three-level node platform for data asset transactions with a mimetic structure, comprising the following steps:

[0006] S1. Initialize the system and register the IP address and port information accessed by external entities;

[0007] S2, the executor scheduler receives the task request from the mimic distributor and selects an executor for task allocation;

[0008] S3, the executor scheduler returns the IP address of the selected executor to the mimic distributor;

[0009] S4, the mimic distributor distributes the access request information to the specified executor and starts task processing;

[0010] S5. The executor processes the access request of the mimic distributor and sends the processing result to the mimic decision gateway for consistency voting;

[0011] S6. The mimic arbitration gateway performs consistency voting on the results of multiple executors. If the votes are consistent, the execution continues. If the votes are inconsistent, the exception is recorded and rescheduling is triggered.

[0012] S7. Call the corresponding interface to execute the task according to the request type and target and microservice type.

[0013] As a further improvement of the technical solution, in S1, the system is initialized and the IP address and port information accessed by the external entity are registered. The specific steps are as follows:

[0014] S1.1. The system identifies and records the IP addresses of external entities that interact with the system;

[0015] S1.2. The system records the port number used by external entities for access;

[0016] S1.3, after registering the IP address and port information, the system is ready to execute the body scheduling;

[0017] The external entities include user terminals, external applications and system components.

[0018] As a further improvement of the technical solution, in S2, the executor scheduler receives the request of the mimic distributor and selects an executor for task allocation. The specific steps are as follows:

[0019] S2.1, the mimic distributor sends a task request to the executor scheduler according to the request of the external entity;

[0020] S2.2, the executor scheduler receives the task request from the mimic distributor and parses the task priority, resource requirements and execution time limit information in the task request from the mimic distributor;

[0021] S2.3, the executor scheduler records the status of all available executors, and selects the appropriate executor based on the executor status using the minimum load priority scheduling algorithm;

[0022] S2.4, after selecting a suitable executor, the executor scheduler assigns the mimic dispatcher task request to the selected executor;

[0023] S2.5. After the mimic dispatcher assigns the task request, the scheduler updates the executor status information.

[0024] As a further improvement of the technical solution, in S2.2, the mimic distributor task request includes the type of request, priority, and number of required resources;

[0025] In S2.3, the execution state includes load condition, execution capability and current number of tasks;

[0026] In S2.4, the executor scheduler will assign the mimic distributor task request to the selected executor, and the specific steps include: transmitting request parameters, allocating computing resources, and initializing the task execution environment.

[0027] As a further improvement of the technical solution, in S2.3, the executor scheduler records the status of all available executors, and selects a suitable executor based on the executor status by using the minimum load priority scheduling algorithm. The specific steps are as follows:

[0028] S2.3.1. The scheduler traverses all executables E in the state table = {e1, e2, ..., e n}, calculate and compare the load value L(e i );

[0029] S2.3.2. Use the minimum load priority scheduling algorithm to select the appropriate executor selected ;

[0030]

[0031] Among them, e selected is the selected executable with the smallest load; arg min is the operator for finding the minimum value of the parameter; E is the set of executables.

[0032] As a further improvement of the technical solution, in S3, the executor scheduler returns the IP address of the selected executor to the mimic distributor, and the specific steps are as follows:

[0033] S3.1, the execution body scheduler will find the execution body e from the execution body state table selected IP address;

[0034] S3.2, the execution body scheduler will select the execution body e selected The IP address is encapsulated into a network information packet and sent to the mimic distributor through the system's internal communication mechanism;

[0035] S3.3, the mimic distributor receives the executable e selected After receiving the IP address information, a confirmation signal ACK is sent back to the executor scheduler.

[0036] As a further improvement of the technical solution, in S4, the mimic distributor distributes the access request information to the designated execution body and starts task processing. The specific steps are as follows:

[0037] S4.1, after receiving the network information of the executable, the mimic distributor encapsulates the external entity access request information;

[0038] S4.2. Establishing the mimic distributor and executorselected Network connections between

[0039] S4.3, Executor e selected The parsing receives the access request from the mimic distributor and sends a confirmation ACK signal to the mimic distributor.

[0040] As a further improvement of the technical solution, in S5, the executor processes the access request of the mimic distributor and sends the processing result to the mimic arbitration gateway for consistency voting;

[0041] S5.1, the executor parses the access request of the mimic distributor and processes the task according to the parsed task type;

[0042] S5.2, after the task processing is completed, the execution body generates the processing result and encapsulates the processing result into a data packet;

[0043] S5.3. Use the system's internal network protocol TCP / IP to establish a communication connection between the executive and the mimicry arbitration gateway;

[0044] S5.4, the executor sends the encapsulated data packet to the mimic decision gateway;

[0045] S5.5. The mimetic decision gateway receives processing results from multiple executors, aggregates these results, and performs a consensus vote.

[0046] As a further improvement of the technical solution, in S6, the mimic arbitration gateway performs consistency voting on the results of multiple execution bodies. If the votes are consistent, the execution continues. If the votes are inconsistent, the exception is recorded and rescheduling is triggered. The specific steps are as follows:

[0047] S6.1. The decision gateway performs a preliminary check on the received results and removes the results with missing data and incorrect format;

[0048] S6.2, the decision gateway compares the result data returned by each execution body one by one. If the result data is completely consistent, it will be directly voted; if there is a difference in the data, it will enter the next step of majority voting;

[0049] S6.3. Use majority voting rules to conduct consensus voting. If the majority of results are consistent, then the result is selected as the final processing result;

[0050] S6.4. If the consensus vote fails, the decision gateway will mark the request as an exception and record the exception information, including the request ID, result data, identifier and timestamp. The decision gateway will also feedback the exception to the executor scheduler.

[0051] As a further improvement of the technical solution, in S7, the corresponding interface is called to execute the task according to the type and target of the request and the type of microservice, as follows:

[0052] S7.1. Select the data tool management microservice, data asset management microservice, and data transaction management microservice based on the request type;

[0053] S7.2. When selecting a data tool management microservice, call the data tool classification query, data model interface, and data tool interface;

[0054] S7.3. When selecting the data asset management microservice, call the third-party data asset interface and the third-party data source interface;

[0055] S7.4. When selecting the data transaction management microservice, call price inquiry, transaction registration, fingerprint verification, third-party transaction verification interface, third-party settlement interface and third-party identity authentication platform.

[0056] Compared with the prior art, the present invention has the following beneficial effects:

[0057] 1. In the design method of a three-level node platform for data asset transactions with a mimetic structure, the dynamic, heterogeneous and redundant mimetic defense architecture can effectively resist various network attacks and ensure the consistency of processing results and high availability of the system during data transactions.

[0058] 2. In the design method of a three-level node platform for data asset transactions with a mimetic structure, the real-time dynamic scheduling of data transaction tasks and parallel processing of multiple executors are realized through the collaborative work of core functional components such as mimetic distribution, mimetic arbitration, feedback control and executor scheduling, thereby enhancing the platform's adaptability and protection capabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 is a flow chart of the overall method of the present invention;

[0060] Figure 2 This is a schematic diagram of the mimicry transformation of the third-level node platform for data asset transactions. DETAILED DESCRIPTION

[0061] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0062] See also Figure 1 and Figure 2As shown, this embodiment provides a method for designing a three-level node platform for data asset transactions with a mimetic structure, including the following steps:

[0063] S1. Initialize the system and register the IP address and port information accessed by external entities;

[0064] Initialize the system and register the IP address and port information accessed by external entities. The specific steps are as follows:

[0065] S1.1. The system identifies and records the IP addresses of external entities that interact with the system;

[0066] S1.2. The system records the port number used by external entities for access;

[0067] S1.3, after registering the IP address and port information, the system is ready to execute the body scheduling;

[0068] The external entities include user terminals, external applications and system components.

[0069] The purpose of registering the IP address for external access is to ensure that the system can correctly identify and verify access requests from the outside to prevent unauthorized access; the port number specifies the specific path for access requests to enter the system and is an indispensable part of network communication. By registering the port information, the system can correctly monitor and receive requests from the outside to ensure that the data flow can smoothly enter the system for processing;

[0070] The executor is the working unit in the system responsible for specific task processing. During the initialization phase, the system needs to ensure that the executor scheduler is in a ready state so that it can quickly select a suitable executor for task processing when a request is received. This step includes checking the status of the executor resource pool, preloading the executor, and initializing the executor scheduling strategy.

[0071] S2, the executor scheduler receives the task request from the mimic distributor and selects an executor for task allocation;

[0072] The executor scheduler receives the request from the mimic dispatcher and selects an executor for task allocation. The specific steps are as follows:

[0073] S2.1, the mimic distributor sends a task request to the executor scheduler according to the request of the external entity;

[0074] S2.2, the executor scheduler receives the task request from the mimic distributor and parses the task priority, resource requirements and execution time limit information in the task request from the mimic distributor;

[0075] S2.3, the executor scheduler records the status of all available executors, and selects the appropriate executor based on the executor status using the minimum load priority scheduling algorithm;

[0076] S2.4, after selecting a suitable executor, the executor scheduler assigns the mimic dispatcher task request to the selected executor;

[0077] S2.5. After the mimic dispatcher assigns the task request, the scheduler updates the executor status information.

[0078] In this embodiment S2.2, the mimic distributor task request includes the type of request, priority, and number of required resources;

[0079] In S2.3, the state of the executor includes the load condition, execution capacity, and the number of current tasks;

[0080] In S2.4, the executor scheduler will assign the mimic distributor task request to the selected executor. The specific steps include: passing request parameters, allocating computing resources, and initializing the task execution environment.

[0081] In S2.3 of this embodiment, the executor scheduler records the status of all available executors, and selects a suitable executor based on the executor status by using the minimum load priority scheduling algorithm. The specific steps are as follows:

[0082] S2.3.1. The scheduler traverses all executables E in the state table = {e1, e2, ..., e n}, calculate and compare the load value L(e i );

[0083] S2.3.2. Use the minimum load priority scheduling algorithm to select the appropriate executor selected ;

[0084]

[0085] Among them, e selected is the selected executable with the smallest load; arg min is the operator for finding the minimum value of the parameter; E is the set of executables.

[0086] S3, the executor scheduler returns the IP address of the selected executor to the mimic distributor;

[0087] The executor scheduler returns the IP address of the selected executor to the mimic distributor. The specific steps are as follows:

[0088] S3.1, the execution body scheduler will find the execution body e from the execution body state table selected IP address;

[0089] S3.2, the execution body scheduler will select the execution body e selected The IP address is encapsulated into a network information packet and sent to the mimic distributor through the system's internal communication mechanism;

[0090] S3.3, the mimic distributor receives the executable e selected After receiving the IP address information, a confirmation signal ACK is sent back to the executor scheduler.

[0091] The data structure used to store and manage the status information of all available executors in the system is maintained by the scheduler and is updated regularly to reflect the current status of each executor. The information in the executor status table usually includes:

[0092] IP address: the network address of the executable, used for network communication;

[0093] Port number: The port number that the executor listens on, used for access together with the IP address;

[0094] Current load: the number of tasks or load conditions that the executor is processing;

[0095] Available resources: the remaining resources of the executable, such as CPU, memory, etc.

[0096] Health status: the running status of the executor, indicating whether the executor is in normal working condition;

[0097] A network packet is a unit of data transmitted over a network. It is a standardized data format used to transmit data between communication devices. A network packet consists of the following parts:

[0098] Header: Contains control information, such as the sender and receiver's addresses, data type, data length, etc.

[0099] Data part: the actual data content to be transmitted, such as IP address, port number, etc.

[0100] Tail: used for verification and data integrity, including information such as checksum.

[0101] In S3.2, the executor scheduler encapsulates the IP address and port number of the selected executor into a network information packet in order to ensure the format standardization and integrity of data when it is transmitted within the system;

[0102] The internal communication mechanism is the protocol for information exchange between components within the system;

[0103] The confirmation signal ACK is a simple feedback mechanism used to confirm that the receiver has successfully received and processed the information sent by the sender. The specific process is as follows:

[0104] Send ACK signal: After receiving the network information packet sent by the executor scheduler, the mimic distributor will parse the IP address and port number in the packet; if the information packet is received and processed correctly, the mimic distributor will send an ACK signal back to the executor scheduler, indicating that the data was received successfully;

[0105] Transmission of ACK signal: The ACK signal can be returned to the scheduler through the same communication mechanism as the sent packet. The ACK signal usually contains only a small amount of information, including a successful reception indicator and an identifier of the original packet.

[0106] S4, the mimic distributor distributes the access request information to the specified executor and starts task processing;

[0107] The mimic distributor distributes the access request information to the specified executor and starts task processing. The specific steps are as follows:

[0108] S4.1, after receiving the network information of the executable, the mimic distributor encapsulates the external entity access request information;

[0109] S4.2. Establishing the mimic distributor and executor selected Network connections between

[0110] S4.3, Executor e selected The parsing receives the access request from the mimic distributor and sends a confirmation ACK signal to the mimic distributor.

[0111] Encapsulates external entity access request information including:

[0112] Request identifier: an ID that uniquely identifies this request;

[0113] Request data: the data payload contained in the request, including user input data and query parameters;

[0114] Task type: identifies the type of request, including query, update, and delete;

[0115] Timestamp: records the time of the request for subsequent auditing and synchronization.

[0116] S5. The executor processes the access request of the mimic distributor and sends the processing result to the mimic decision gateway for consistency voting;

[0117] The executor processes the access request of the mimic distributor and sends the processing result to the mimic decision gateway for consistency voting;

[0118] S5.1, the executor parses the access request of the mimic distributor and processes the task according to the parsed task type;

[0119] S5.2, after the task processing is completed, the execution body generates the processing result and encapsulates the processing result into a data packet;

[0120] S5.3. Use the system's internal network protocol TCP / IP to establish a communication connection between the executive and the mimicry arbitration gateway;

[0121] S5.4, the executor sends the encapsulated data packet to the mimic decision gateway;

[0122] S5.5. The mimetic decision gateway receives processing results from multiple executors, aggregates these results, and performs a consensus vote.

[0123] After the task is processed, the execution will generate the processing results, which include:

[0124] Task identifier: an identifier corresponding to the original request, used to track the processing of the task;

[0125] Processing results: output data after task processing, including query results, calculation results, update confirmation, etc.;

[0126] Processing status: indicates the execution status of the task, including success, failure, or partial completion;

[0127] Timestamp: records the time when the task is completed, which is convenient for subsequent audit and synchronization operations;

[0128] The encapsulated data packet includes fields such as task identifier, processing result, and processing status;

[0129] The voting process is as follows:

[0130] Preliminary check: The adjudication gateway first checks whether the results returned by each executor conform to the expected format and content. If there are obviously wrong results, they will be directly rejected;

[0131] Consistency comparison: Compare the result data of each execution body one by one to find out the same or different parts;

[0132] Final decision: According to the majority voting rule, a consistent result is selected as the final processing result. If the results of all executors are consistent, the decision is passed directly by voting; if they are inconsistent, the exception handling mechanism may be triggered.

[0133] S6. The mimic arbitration gateway performs consistency voting on the results of multiple executors. If the votes are consistent, the execution continues. If the votes are inconsistent, the exception is recorded and rescheduling is triggered.

[0134] The mimic arbitration gateway performs consistency voting on the results of multiple executors. If the votes are consistent, the execution continues. If the votes are inconsistent, the exception is recorded and rescheduling is triggered. The specific steps are as follows:

[0135] S6.1. The decision gateway performs a preliminary check on the received results and removes the results with missing data and incorrect format;

[0136] S6.2, the decision gateway compares the result data returned by each execution body one by one. If the result data is completely consistent, it will be directly voted; if there is a difference in the data, it will enter the next step of majority voting;

[0137] S6.3. Use majority voting rules to conduct consensus voting. If the majority of results are consistent, then the result is selected as the final processing result;

[0138] S6.4. If the consensus vote fails, the decision gateway will mark the request as an exception and record the exception information, including the request ID, result data, identifier and timestamp. The decision gateway will also feedback the exception to the executor scheduler.

[0139] S7. Call the corresponding interface to execute the task according to the type and target of the request and the type of microservice;

[0140] Call the corresponding interface to perform tasks according to the request type and target as well as the microservice type, as follows:

[0141] S7.1. Select the data tool management microservice, data asset management microservice, and data transaction management microservice based on the request type;

[0142] S7.2. When selecting a data tool management microservice, call the data tool classification query, data model interface, and data tool interface;

[0143] S7.3. When selecting the data asset management microservice, call the third-party data asset interface and the third-party data source interface;

[0144] S7.4. When selecting the data transaction management microservice, call price inquiry, transaction registration, fingerprint verification, third-party transaction verification interface, third-party settlement interface and third-party identity authentication platform.

[0145] The above shows and describes the basic principles, main features and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited by the above embodiments, and the above embodiments and descriptions are only preferred examples of the present invention, and are not intended to limit the present invention. Without departing from the spirit and scope of the present invention, the present invention may have various changes and improvements, and these changes and improvements all fall within the scope of the present invention to be protected.

Claims

1. A method for designing a three-level node platform for data asset transactions with a mimetic structure, characterized by: The following steps are involved: S1. Initialize the system and register the IP address and port information accessed by external entities; S2, the executor scheduler receives the task request from the mimic distributor and selects an executor for task allocation; S3, the executor scheduler returns the IP address of the selected executor to the mimic distributor; S4, the mimic distributor distributes the access request information to the specified executor and starts task processing; S5. The executor processes the access request of the mimic distributor and sends the processing result to the mimic decision gateway for consistency voting; S6. The mimic arbitration gateway performs consistency voting on the results of multiple executors. If the votes are consistent, the execution continues. If the votes are inconsistent, the exception is recorded and rescheduling is triggered. S7. Call the corresponding interface to execute the task according to the request type and target and microservice type.

2. The method for designing a three-level node platform for data asset transactions with a mimetic structure according to claim 1 is characterized by: In S1, the system is initialized and the IP address and port information accessed by the external entity are registered. The specific steps are as follows: S1.

1. The system identifies and records the IP addresses of external entities that interact with the system; S1.

2. The system records the port number used by external entities for access; S1.3, after registering the IP address and port information, the system is ready to execute the body scheduling; The external entities include user terminals, external applications and system components.

3. The method for designing a three-level node platform for data asset transactions with a mimetic structure according to claim 1 is characterized by: In S2, the executor scheduler receives the request from the mimic distributor and selects an executor for task allocation. The specific steps are as follows: S2.1, the mimic distributor sends a task request to the executor scheduler according to the request of the external entity; S2.2, the executor scheduler receives the task request from the mimic distributor and parses the task priority, resource requirements and execution time limit information in the task request from the mimic distributor; S2.3, the executor scheduler records the status of all available executors, and selects the appropriate executor based on the executor status using the minimum load priority scheduling algorithm; S2.4, after selecting a suitable executor, the executor scheduler assigns the mimic dispatcher task request to the selected executor; S2.

5. After the mimic dispatcher assigns the task request, the scheduler updates the executor status information.

4. The method for designing a three-level node platform for data asset transactions with a mimetic structure according to claim 3 is characterized by: In said S2.2, the mimic distributor task request includes the type of request, priority and number of required resources; In S2.3, the execution state includes load condition, execution capability and current number of tasks; In S2.4, the executor scheduler will assign the mimic distributor task request to the selected executor, and the specific steps include: transmitting request parameters, allocating computing resources, and initializing the task execution environment.

5. The method for designing a three-level node platform for data asset transactions with a mimetic structure according to claim 3 is characterized by: In S2.3, the executor scheduler records the status of all available executors, and selects a suitable executor based on the executor status by using the minimum load priority scheduling algorithm. The specific steps are as follows: S2.3.

1. The scheduler traverses all executables E in the state table = {e1, e2, ..., e n }, calculate and compare the load value L(e i ); S2.3.

2. Use the minimum load priority scheduling algorithm to select the appropriate executor selected ; Among them, e selected is the selected executable with the smallest load; arg min is the operator for finding the minimum value of the parameter; E is the set of executables.

6. The method for designing a three-level node platform for data asset transactions with a mimetic structure according to claim 1 is characterized by: In S3, the executor scheduler returns the IP address of the selected executor to the mimic distributor. The specific steps are as follows: S3.1, the execution body scheduler will find the execution body e from the execution body state table selected IP address; S3.2, the execution body scheduler will select the execution body e selected The IP address is encapsulated into a network information packet and sent to the mimic distributor through the system's internal communication mechanism; S3.3, the mimic distributor receives the executable e selected After receiving the IP address information, a confirmation signal ACK is sent back to the executor scheduler.

7. The method for designing a three-level node platform for data asset transactions with a mimetic structure according to claim 1 is characterized by: In S4, the mimic distributor distributes the access request information to the specified execution body and starts task processing. The specific steps are as follows: S4.1, after receiving the network information of the executable, the mimic distributor encapsulates the external entity access request information; S4.

2. Establishing the mimic distributor and executor selected Network connections between S4.3, Executor e selected The parsing receives the access request from the mimic distributor and sends a confirmation ACK signal to the mimic distributor.

8. The method for designing a three-level node platform for data asset transactions with a mimetic structure according to claim 1 is characterized by: In S5, the executor processes the access request of the mimetic distributor and sends the processing result to the mimetic arbitration gateway for consistency voting; S5.1, the executor parses the access request of the mimic distributor and processes the task according to the parsed task type; S5.2, after the task processing is completed, the execution body generates the processing result and encapsulates the processing result into a data packet; S5.

3. Use the system's internal network protocol TCP / IP to establish a communication connection between the executive and the mimicry arbitration gateway; S5.4, the executor sends the encapsulated data packet to the mimic decision gateway; S5.

5. The mimetic decision gateway receives processing results from multiple executors, aggregates these results, and performs a consensus vote.

9. The method for designing a three-level node platform for data asset transactions with a mimetic structure according to claim 1 is characterized by: In S6, the mimic arbitration gateway performs consistency voting on the results of multiple execution bodies. If the votes are consistent, the execution continues. If the votes are inconsistent, the exception is recorded and rescheduling is triggered. The specific steps are as follows: S6.

1. The decision gateway performs a preliminary check on the received results and removes the results with missing data and incorrect format; S6.2, the decision gateway compares the result data returned by each execution body one by one. If the result data is completely consistent, it will be directly voted; if there is a difference in the data, it will enter the next step of majority voting; S6.

3. Use majority voting rules to conduct consensus voting. If the majority of results are consistent, then the result is selected as the final processing result; S6.

4. If the consensus vote fails, the decision gateway will mark the request as an exception and record the exception information, including the request ID, result data, identifier and timestamp. The decision gateway will also feedback the exception to the executor scheduler.

10. The method for designing a three-level node platform for data asset transactions with a mimetic structure according to claim 1 is characterized by: In S7, the corresponding interface is called to execute the task according to the type and target of the request and the type of microservice, as follows: S7.

1. Select the data tool management microservice, data asset management microservice, and data transaction management microservice based on the request type; S7.

2. When selecting a data tool management microservice, call the data tool classification query, data model interface, and data tool interface; S7.

3. When selecting the data asset management microservice, call the third-party data asset interface and the third-party data source interface; S7.

4. When selecting the data transaction management microservice, call price inquiry, transaction registration, fingerprint verification, third-party transaction verification interface, third-party settlement interface and third-party identity authentication platform.

Images