Processing method and device for chaining task on block chain, storage medium and electronic equipment

Abstract

The invention provides a block chain uplink task processing method and device, a storage medium and electronic equipment, and relates to the technical field of computers.The method comprises the steps that an uplink task reported by a service system is received; the uplink task is a task to be submitted to a block chain network by a task execution node; determining an initial priority of the uplink task based on the task scene and the task generation time of the uplink task; obtaining a current first resource state of a block chain node in the block chain network, a current second resource state of the task execution node and a task operation index; based on the first resource state, the second resource state and the task operation index, determining the execution priority and the uplink rate of the uplink task; and controlling the task execution node to execute the uplink task based on the execution priority and the uplink rate. By applying the method provided by the embodiment of the invention, the uplink efficiency can be effectively improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, storage medium, and electronic device for processing blockchain on-chain tasks. Background Technology

[0002] With the widespread application of blockchain technology, data from various business scenarios such as financial reconciliation, message push, and digital identity often needs to be uploaded to the blockchain concurrently. However, the processing resources of the blockchain network and its task execution nodes, such as network bandwidth, CPU computing power, and on-chain transaction processing capacity, are limited within a specific time frame. When data from multiple scenarios is uploaded to the blockchain concurrently, it triggers fierce competition for limited resources. Especially in high-time-sensitivity scenarios, the timeliness of data upload is easily blocked by resource-intensive tasks. Furthermore, at specific business moments, such as when data discrepancies trigger packet splitting, the number of upload requests surges, causing the pressure of resource competition to increase exponentially.

[0003] Currently, the industry generally uses solutions such as static priority queues or fixed rate limits for on-chain task management. However, static priority cannot detect real-time load changes in the system, and high-priority tasks will also fail when resources are exhausted. Fixed rate limits lack flexibility, cannot improve throughput when resources are sufficient, and are difficult to adapt to sudden traffic downgrades. Summary of the Invention

[0004] The technical problem this application aims to solve is to provide a method, apparatus, storage medium, and electronic device for processing blockchain on-chain tasks, which can effectively improve on-chain efficiency. The specific solution is as follows:

[0005] A method for processing blockchain on-chain tasks includes:

[0006] Receive on-chain tasks reported by the business system; the on-chain tasks are tasks to be submitted to the blockchain network by the task execution node.

[0007] Based on the task scenario and task generation time of the on-chain task, the initial priority of the on-chain task is determined;

[0008] Obtain the current first resource status of the blockchain nodes in the blockchain network, the current second resource status of the task execution node, and the task operation indicators;

[0009] Based on the first resource status, the second resource status, and the task operation indicators, the execution priority and on-chain rate of the on-chain task are determined.

[0010] The task execution node is controlled to execute the on-chain task based on the execution priority and on-chain rate.

[0011] Optionally, in the above method, determining the initial priority based on the task scenario and task generation time of the on-chain task includes:

[0012] Based on the preset scenario timeliness requirements and hierarchical mapping relationship, determine the hierarchical priority corresponding to the task scenario;

[0013] Parse the metadata of the on-chain task to obtain its task generation timestamp and on-chain batch number;

[0014] The initial priority of the on-chain task is calculated based on the hierarchical priority, the task generation timestamp, and the on-chain batch number.

[0015] Optionally, in the above method, obtaining the current first resource status of the blockchain node in the blockchain network, the current second resource status of the task execution node, and the task execution metrics includes:

[0016] Send a query request to the blockchain node to obtain the first resource status of the blockchain node, the first resource status including block height, number of transactions to be confirmed on the chain, and block height change rate;

[0017] Monitor the task execution node to obtain a second resource status, which includes remaining available memory, remaining available CPU computing power, and remaining available network bandwidth.

[0018] The task execution metrics are collected from the task execution log of the task execution node. The task execution metrics include the task on-chain success rate, the task on-chain time, and the number of task failures.

[0019] Optionally, in the above method, determining the execution priority and on-chain rate of the on-chain task based on the first resource status, the second resource status, and the task operation indicators includes:

[0020] Based on the current and historical states of the first and second resources, the maximum on-chain rate and the recommended on-chain rate are calculated.

[0021] If the number of task failures in the task operation metrics exceeds a threshold, the initial priority of the on-chain task will be reduced.

[0022] Based on the maximum on-chain rate, the recommended on-chain rate, and the reduced initial priority, the execution priority and on-chain rate of the on-chain task are determined.

[0023] Optionally, after controlling the task execution node to execute the on-chain task based on the execution priority and on-chain rate, the above method further includes:

[0024] After the on-chain task is successfully executed, the task execution result is encapsulated into a transaction and submitted to the blockchain network for on-chain processing, and the on-chain transaction hash is obtained.

[0025] The on-chain transaction hash, task execution status, and completion timestamp are associated and stored in the business database.

[0026] A device for processing blockchain on-chain tasks, comprising:

[0027] The receiving unit is used to receive on-chain tasks reported by the business system; the on-chain tasks are tasks to be submitted to the blockchain network by the task execution node.

[0028] The first determining unit is used to determine the initial priority of the on-chain task based on the task scenario and task generation time of the on-chain task.

[0029] The acquisition unit is used to acquire the current first resource status of the blockchain node in the blockchain network, the current second resource status of the task execution node, and the task operation indicators.

[0030] The second determining unit is used to determine the execution priority and on-chain rate of the on-chain task based on the first resource status, the second resource status and the task operation indicators.

[0031] The control unit is used to control the task execution node to execute the on-chain task based on the execution priority and on-chain rate.

[0032] Optionally, the first determining unit in the aforementioned apparatus includes:

[0033] The sub-unit is determined to determine the hierarchical priority corresponding to the task scenario based on the preset scenario timeliness requirements and hierarchical mapping relationship.

[0034] The parsing subunit is used to parse the metadata of the on-chain task to obtain its task generation timestamp and on-chain batch number;

[0035] The calculation subunit is used to calculate the initial priority of the on-chain task based on the hierarchical priority, the task generation timestamp, and the on-chain batch number.

[0036] Optionally, the acquisition unit in the aforementioned apparatus includes:

[0037] The sending subunit is used to send a query request to the blockchain node to obtain the first resource status of the blockchain node, the first resource status including block height, number of transactions to be confirmed on the chain, and block height change rate.

[0038] The monitoring subunit is used to monitor the task execution node and obtain a second resource status, which includes the remaining available memory, the remaining available CPU computing power, and the remaining available network bandwidth.

[0039] The data collection subunit is used to collect the task execution metrics from the task execution log of the task execution node. The task execution metrics include the task on-chain success rate, the task on-chain time, and the number of task failures.

[0040] An electronic device includes a memory and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors in a method for processing blockchain on-chain tasks as described above.

[0041] This application provides a method, apparatus, storage medium, and electronic device for processing blockchain on-chain tasks. The method includes: receiving an on-chain task reported by a business system; the on-chain task is a task to be submitted to the blockchain network by a task execution node; determining the initial priority of the on-chain task based on its task scenario and generation time; obtaining the current first resource status of the blockchain node in the blockchain network, the current second resource status of the task execution node, and task operation indicators; determining the execution priority and on-chain rate of the on-chain task based on the first resource status, the second resource status, and the task operation indicators; and controlling the task execution node to execute the on-chain task based on the execution priority and on-chain rate. Applying the method provided in this application can effectively improve on-chain efficiency. Attached Figure Description

[0042] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0043] Figure 1 A flowchart illustrating a method for processing blockchain on-chain tasks provided in this application;

[0044] Figure 2 An example scenario diagram provided for this application;

[0045] Figure 3 A schematic diagram of the structure of a blockchain on-chain task processing device provided in this application;

[0046] Figure 4 This is a schematic diagram of the structure of an electronic device provided in this application. Detailed Implementation

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

[0048] In this application, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0049] This application provides a method for processing on-chain tasks in a blockchain. This method can be applied to blockchain nodes, management nodes, task execution nodes, etc., within a blockchain. The flowchart of the method is shown below. Figure 1 As shown, it specifically includes:

[0050] S101: Receive on-chain tasks reported by the business system; on-chain tasks are tasks that are to be submitted to the blockchain network by the task execution node.

[0051] In this embodiment, an on-chain task refers to a data unit that needs to be recorded on the blockchain. These data units may include, but are not limited to, reconciliation data, push data, or digital identity data. For example, each on-chain task contains specific task metadata, such as an on-chain hash value, an on-chain batch number, and a timestamp accurate to the minute and second. The on-chain batch number is typically a unique identifier generated at 00:00:00 every hour, used to distinguish tasks generated in different batches. These tasks are proactively reported by the business system, then wait to be processed by the task execution nodes and finally submitted to the blockchain network for storage.

[0052] S102: Determine the initial priority of the on-chain task based on the task scenario and task generation time.

[0053] In this embodiment, the task scenario refers to the business type to which the on-chain task belongs, such as reconciliation, push notifications, or digital identity scenarios. Each scenario has specific timeliness requirements, which are usually pre-set by administrators based on business importance, forming different levels of hierarchical priority. Additionally, the task generation time refers to the timestamp recorded when the task is created by the business system, including the specific minute and second values. In implementation, the system comprehensively considers the hierarchical priority corresponding to the task scenario and the order of task generation times, generating an initial priority through a specific priority calculation function. It's easy to understand that hierarchical priority provides a coarse-grained priority division, while task generation time provides a fine-grained adjustment basis, ensuring that tasks within the same level are reasonably ordered according to their generation time.

[0054] S103: Obtain the current first resource status of the blockchain node, the current second resource status of the task execution node, and the task operation indicators in the blockchain network.

[0055] In this embodiment, the first resource status mainly refers to the current operating status of the blockchain node, including but not limited to key indicators such as the node's current block height, the number of transactions awaiting confirmation on the chain, and the rate of block height change. The second resource status focuses on the resource usage of the task execution node, typically including the node's remaining available memory, remaining CPU computing power, and available network bandwidth. Additionally, task execution metrics reflect the historical performance of the task, such as the success rate of task on-chain processing, average on-chain processing time, and the number of task failures. In implementation, these metrics are collected and reported in real time by each node, and ultimately centrally stored in a caching middleware or database for subsequent analysis and decision-making. By simultaneously monitoring the status of both the blockchain node and the task execution node, the system can comprehensively grasp the operating status of the entire on-chain environment.

[0056] S104: Based on the first resource status, the second resource status, and task operation indicators, determine the execution priority and on-chain rate of the on-chain task.

[0057] In this embodiment, the system comprehensively analyzes various indicators collected from blockchain nodes and task execution nodes to dynamically adjust the execution strategy of on-chain tasks. Specifically, based on current and historical resource status data, the system calculates the maximum on-chain rate that the system can support at the current moment and the recommended stable on-chain rate. Furthermore, the system pays special attention to failure rates in task execution indicators; when a task fails multiple times, a backoff mechanism automatically lowers its priority. Finally, the system combines the maximum on-chain rate, the stable on-chain rate, and the adjusted task priority to generate the final execution priority and on-chain rate control strategy. This dynamic adjustment mechanism allows the system to adaptively adjust the task execution strategy according to real-time load conditions, effectively avoiding system overload.

[0058] S105: Control task execution nodes execute on-chain tasks based on execution priority and on-chain rate.

[0059] In this embodiment, task execution nodes process on-chain tasks based on adjusted execution priorities and on-chain speeds. In practice, nodes use a weighted round-robin approach to retrieve tasks from the task queue, assigning higher-priority tasks higher weights to gain more execution opportunities. Simultaneously, each execution node calculates its processing capacity limit based on its remaining resources, including available memory, CPU, and bandwidth, to determine the actual execution rate. After successful task execution, the node submits the task execution result and related hash value to the blockchain network, while persistently storing metadata such as execution status and completion time in the database and cache. In this way, the system ensures both timely processing of high-priority tasks and reliable storage and queryability of task execution results.

[0060] In one embodiment provided in this application, based on the above-described scheme, optionally, the initial priority is determined based on the task scenario and task generation time of the on-chain task, including:

[0061] Based on the preset timeliness requirements and hierarchical mapping relationship of the scenario, determine the hierarchical priority corresponding to the task scenario;

[0062] Parse the metadata of the on-chain task to obtain its task generation timestamp and on-chain batch number;

[0063] The initial priority of the on-chain task is calculated based on the hierarchical priority, the task generation timestamp, and the batch number on the chain.

[0064] In this embodiment, the scenario timeliness requirement refers to the specific needs of different business scenarios for the timeliness of data uploading to the blockchain. For example, reconciliation data may require uploading to the blockchain within one hour, while push data may require uploading to the blockchain within one minute. These timeliness requirements are usually preset by system administrators based on business importance. The hierarchical mapping relationship refers to the corresponding rules that map different business scenarios to corresponding priority levels. This mapping relationship is usually stored in the system configuration file in the form of a configuration table. A common practice is to map the business scenario with the highest requirement to the first level, the next highest requirement to the second level, and so on, thus forming a hierarchical priority system.

[0065] In implementation, when determining hierarchical priorities, the system first needs to identify the specific business scenario to which the on-chain task belongs, and then obtain the corresponding hierarchical priority value for that business scenario by querying a preset hierarchical mapping configuration table. It's easy to understand that this hierarchical priority setting is actually a coarse-grained priority control method, providing a basic distinction of importance for business scenarios of different levels of importance.

[0066] Additionally, the task generation timestamp refers to the time information recorded by the business system when the on-chain task is created, typically including specific time units such as hour, minute, and second. In practical implementations, the timestamp precision can reach the millisecond level, ensuring that multiple tasks generated within the same second can be correctly distinguished in order. The on-chain batch number is a batch identifier generated by the system according to a predetermined time period. A typical approach is to automatically generate a new batch number at 00:00 every hour. This batch number is usually represented by an incrementing numerical sequence or a string in a specific format.

[0067] When parsing the metadata of on-chain tasks, the system needs to extract fields containing the task generation timestamp and on-chain batch number from the task message, and then perform format parsing and data validation on these fields. Considering that different business systems may use different time formats, it is usually necessary to first convert the timestamps of various formats into a standard internal system time format in order to enable accurate time comparison and calculation later.

[0068] When calculating the initial priority, the system needs to comprehensively consider three dimensions: hierarchical priority, task generation timestamp, and on-chain batch number. Hierarchical priority provides the basic importance weight, the task generation timestamp ensures temporal fairness, and the on-chain batch number distinguishes task batches generated in different time periods. For example, a common calculation method is to use the hierarchical priority as the base value, and then perform a weighted calculation combining the task generation timestamp and the on-chain batch number. Specifically, the task generation timestamp can first be converted into an offset relative to the batch start time, and then this offset can be combined with the hierarchical priority using a specific algorithm to obtain the final initial priority value.

[0069] It's worth noting that, due to significant differences in timeliness requirements across various business scenarios, different calculation parameters may need to be set for different priority levels during implementation. For example, for high-priority business scenarios, the weight of timestamps in the calculation can be appropriately increased to ensure that tasks with high timeliness requirements are processed more promptly. Furthermore, considering system performance factors, the calculated initial priority may be normalized in practical applications, mapping it to a fixed numerical range. This facilitates subsequent priority comparisons and scheduling.

[0070] The initial priority determined through the above method considers both the differences in the importance of business scenarios and the chronological order of task generation, while also effectively distinguishing different batches of tasks through on-chain batch numbers. This design provides a reliable basis for subsequent dynamic priority adjustments, ensuring that data from time-sensitive business scenarios receives priority for on-chain processing.

[0071] In one embodiment provided in this application, based on the above-described scheme, optionally, obtaining the current first resource status of the blockchain node in the blockchain network, the current second resource status of the task execution node, and task operation indicators includes:

[0072] Send a query request to the blockchain node to obtain the first resource status of the blockchain node. The first resource status includes the block height, the number of transactions to be confirmed on the chain, and the block height change rate.

[0073] Monitor the task execution node to obtain the second resource status, which includes the remaining available memory, the remaining available CPU computing power, and the remaining available network bandwidth.

[0074] Collect task execution metrics from the task execution log of the task execution node. These metrics include task on-chain success rate, task on-chain time, and number of task failures.

[0075] In this embodiment, a query request refers to a resource status query instruction issued by the system to a blockchain node, which is typically implemented through a specific remote procedure call protocol. The block height represents the sequence number of the latest block in the blockchain network, reflecting the growth of the blockchain. The number of on-chain pending transactions refers to the number of transactions waiting to be packaged into a block in the blockchain network's transaction pool; this metric directly reflects the current network congestion level. The block height change rate refers to the rate at which the block height increases per unit of time, calculated by the ratio of the difference in block height between two adjacent time points to the duration of the change; this metric can be used to assess the block production stability of the blockchain network.

[0076] In implementation, when acquiring the initial resource status, the system periodically sends status query requests to the blockchain nodes. A common practice is to use a JSON-RPC interface to call the data query service provided by the blockchain nodes to obtain real-time on-chain data, including block height and the number of pending transactions. Furthermore, calculating the block height change rate requires the system to record historical block height information. By comparing the current block height with the block height of the previous sampling period and considering the time interval, the change rate is calculated. This design allows the system to comprehensively grasp the real-time operating status of the blockchain network.

[0077] Monitoring task execution nodes refers to real-time monitoring of their system resource usage. Specifically, remaining available memory refers to the amount of memory currently available on the task execution node, a value obtained through the operating system's memory management interface. Remaining available CPU computing power represents the currently idle computing resources of the task execution node, typically expressed as a percentage. Remaining available network bandwidth refers to the available transmission capacity of the node's network interface, reflecting the node's network communication capacity.

[0078] In practice, monitoring task execution nodes typically require the deployment of resource monitoring agents. These agents periodically collect various resource metrics by calling the system's underlying resource management interfaces. For example, in a Linux system, memory usage can be obtained by parsing the ` / proc / meminfo` file, CPU utilization by parsing the ` / proc / stat` file, and network bandwidth usage by parsing the ` / proc / net / dev` file. This implementation ensures accurate resource data collection without significantly impacting node performance.

[0079] Task execution logs refer to the runtime records generated by task execution nodes during the processing of on-chain tasks. These logs are typically stored in a structured format on the local file system or in a log database. The task on-chain success rate refers to the ratio of the number of successfully on-chain tasks to the total number of tasks within a certain time frame; this metric reflects the reliability of task execution. Task on-chain time refers to the length of time from the start of task execution to successful on-chain completion, including the time spent on multiple stages such as transaction construction, signing, and submission. The number of task failures records the cumulative number of task execution failures; this metric can be used to identify task instances with execution anomalies.

[0080] When collecting task execution metrics, the system needs to parse and analyze task execution logs. A common approach is to use log collection tools to read log files in real time and then extract key metric information using regular expressions or log template matching. Additionally, to calculate the task on-chain success rate, the system needs to statistically analyze the task execution results within a specified time period, dividing the number of successfully marked tasks by the total number of tasks to obtain the success rate. The calculation of the task on-chain time is obtained by analyzing the difference between the task start timestamp and the on-chain completion timestamp.

[0081] It's worth noting that since there may be multiple instances of task execution nodes, a unified metric collection mechanism needs to be established during implementation. A feasible solution is to deploy a centralized log collection system to aggregate log data from all task execution nodes to a central server for processing. This design facilitates unified metric calculation and is beneficial for subsequent data analysis and system optimization.

[0082] The first resource status, second resource status, and task operation indicators obtained through the above methods together constitute the data foundation for the system's dynamic regulation. These indicators reflect the real-time status of the system's operation from different dimensions, providing crucial decision-making basis for subsequent priority adjustments and rate control. Furthermore, the continuous collection of these indicators helps system administrators promptly identify potential performance bottlenecks and anomalies, contributing to the long-term stable operation of the system.

[0083] In one embodiment provided in this application, based on the above-described scheme, optionally, the execution priority and on-chain rate of the on-chain task are determined based on the first resource state, the second resource state, and task operation indicators, including:

[0084] Based on the current and historical first and second resource states, the maximum on-chain rate and the recommended on-chain rate are calculated.

[0085] If the number of task failures in the task execution metrics exceeds the threshold, the initial priority of the on-chain task will be reduced.

[0086] Based on the maximum on-chain rate, the recommended on-chain rate, and the reduced initial priority, the execution priority and on-chain rate of on-chain tasks are determined.

[0087] In this embodiment, the maximum on-chain rate refers to the highest task processing rate that the system can theoretically support under current resource conditions. This value is mainly limited by the resource bottlenecks of blockchain nodes and task execution nodes. The recommended on-chain rate, on the other hand, refers to the task processing rate suggested to ensure stable system operation. This rate is usually lower than the maximum on-chain rate to retain a certain degree of system redundancy. For example, calculating the maximum on-chain rate requires comprehensively considering multiple constraints such as the number of pending transactions on blockchain nodes, the available computing resources of task execution nodes, and network bandwidth. The theoretical upper limit is determined by finding the minimum value among these constraints.

[0088] In implementation, when calculating the maximum on-chain rate, the system needs to analyze resource status data from both the current and historical moments. A common approach is to first calculate the theoretical throughput of the blockchain network based on the number of pending transactions on the blockchain node and the block generation interval. Additionally, it's necessary to estimate the number of tasks a single node can process in parallel based on the remaining available CPU and memory resources of the task execution nodes. Finally, by taking the smaller value of these calculations and considering network bandwidth limitations, the final maximum on-chain rate is obtained. This calculation method ensures that it will not exceed the system's capacity in either aspect.

[0089] When calculating the recommended on-chain rate, the system needs to focus on the statistical analysis results of historical resource status data. Specifically, resource utilization data over a period of time can be selected to calculate the average processing capacity for stable system operation. Additionally, success rate data from task execution metrics should be considered, using the rate range with higher success rates as a reference range for the recommended on-chain rate. It's easy to understand that the recommended on-chain rate is typically set between 70% and 80% of the maximum on-chain rate to effectively avoid system instability caused by excessively high rates.

[0090] The task failure threshold refers to the number of failures that trigger priority adjustments. This threshold is typically set based on the fault tolerance requirements of the business scenario. For example, for business scenarios with high timeliness requirements, a lower failure threshold might be set, such as 2-3 failures triggering priority adjustments; while for ordinary business scenarios, a relatively higher threshold can be set. In practice, this threshold can be dynamically adjusted through system configuration parameters to adapt to the needs of different operating environments.

[0091] When lowering the initial priority, the system employs a backoff mechanism to gradually adjust task priorities. A common approach is to progressively reduce the initial priority based on the number of task failures and the extent to which a threshold is exceeded, according to preset degradation rules. Additionally, while lowering the priority, the system also extends the retry interval to prevent frequently failing tasks from excessively consuming system resources. It's worth noting that the magnitude of the priority reduction is usually proportional to the number of task failures; the more failures, the greater the priority reduction.

[0092] When determining the final execution priority and on-chain rate, the system needs to comprehensively consider three key factors: the maximum on-chain rate, the recommended on-chain rate, and the adjusted task priority. In implementation, a baseline execution rate is first determined based on the recommended on-chain rate, and then resources are allocated according to the priority of each task. Higher-priority tasks receive more execution resource quotas, while lower-priority tasks may need to wait for the system to become idle before being processed. Furthermore, during actual execution, the system monitors resource usage in real time. If actual resource consumption is found to be lower than expected, the execution rate can be appropriately increased, but it cannot exceed the maximum on-chain rate limit.

[0093] The execution priority and on-chain rate determined through the above methods take into account both the system's actual processing capacity and the urgency of different tasks, while also effectively handling execution anomalies through a backoff mechanism. This design ensures that the system maintains high processing efficiency even under resource constraints, while preventing the continuous failure of individual tasks from affecting the normal operation of the entire system. Furthermore, this dynamic adjustment mechanism can adaptively respond to changes in system load, providing differentiated quality of service assurance for business scenarios of varying importance.

[0094] In one embodiment provided in this application, based on the above-described scheme, optionally, after controlling the task execution node to execute the on-chain task based on execution priority and on-chain rate, the method further includes:

[0095] After the on-chain task is successfully executed, the task execution result is encapsulated into a transaction and submitted to the blockchain network for on-chain processing, and the on-chain transaction hash is obtained.

[0096] The on-chain transaction hash, task execution status, and completion timestamp are associated and stored in the business database.

[0097] In this embodiment, the task execution result refers to the output data generated after the task execution node processes the on-chain task. This data contains the core content that needs to be recorded on the blockchain. Encapsulation as a transaction refers to the process of standardizing the task execution result according to the transaction format specified by the blockchain network. For example, this process typically includes serializing the execution result, adding necessary transaction header information, and performing digital signature operations. The transaction header information should at least include basic fields such as transaction version number, initiator address, recipient address, and gas limit. These fields form the basis for the transaction to be identified and processed in the blockchain network.

[0098] In implementation, when encapsulating the task execution result into a transaction, the original execution result data must first be serialized and encoded. A common practice is to use serialization formats such as Protocol Buffers or JSON to convert the structured execution result into a binary data stream. Additionally, according to the specifications of the blockchain network, standard transaction header information needs to be added to the serialized data. It is worth noting that, to ensure transaction security, after the transaction is encapsulated, the complete transaction data must be digitally signed using the private key of the task execution node. This signature information will serve as an important credential of the transaction's legitimacy.

[0099] An on-chain transaction hash is a unique identifier generated after a transaction is submitted to the blockchain network. This hash value is obtained by performing a cryptographic hash operation on the transaction content. In specific implementations, cryptographic hash algorithms such as SHA-256 or Keccak-256 are typically used to generate transaction hashes. This hash value has the property of being immutable; any minor modification to the transaction content will lead to a significant change in the hash value, thus serving as an important basis for verifying the integrity of a transaction.

[0100] When submitting a transaction to the blockchain network, the task execution node needs to establish a connection with the blockchain node through a specific network interface. A common practice is to use remote call protocols such as JSON-RPC or gRPC to send the encapsulated transaction data to the blockchain node's transaction pool. Additionally, appropriate timeouts and retry mechanisms need to be set during the submission process to handle abnormal situations such as network fluctuations or node overload. It's easy to understand that a transaction is not immediately confirmed after submission; it needs to wait for the blockchain network to package it into a new block. During this process, the task execution node needs to continuously monitor the transaction's confirmation status.

[0101] Task execution status refers to the stage a task is in throughout its entire processing lifecycle. These statuses should at least include basic states such as "Executing," "Submitted," "Confirmed," and "Failed." The completion timestamp is the system time recorded when the task executes successfully. This timestamp should be accurate to the millisecond level for subsequent precise time-series analysis. In actual storage, the completion timestamp is typically recorded using the ISO 8601 standard format or the Unix timestamp format.

[0102] When storing the associated data in the business database, it's necessary to establish a mapping between on-chain transaction hashes and task execution status and completion timestamps. A common implementation is to create a dedicated task status table in the business database, which must contain at least a transaction hash field, a status field, and a timestamp field. Furthermore, to facilitate subsequent queries, indexes are typically created on relevant fields, especially a unique index on the transaction hash field, ensuring the uniqueness of each transaction record.

[0103] It's worth noting that during the process of storing data into the business database, the atomicity and consistency of storage operations must be guaranteed. In implementation, database transaction mechanisms can be used to ensure that all data is either stored successfully or rolled back completely, avoiding data inconsistencies. Furthermore, considering data security requirements, it may be necessary to encrypt sensitive data, especially information containing business secrets, which should be appropriately anonymized or encrypted.

[0104] The execution result processing and storage mechanism implemented in this way ensures that task execution results are reliably recorded on the blockchain and that relevant status information is updated to the business database in a timely manner. This design allows the business system to quickly obtain the task execution status by querying the business database, while simultaneously verifying the authenticity and integrity of the execution results on the blockchain through on-chain transaction hashes. Furthermore, this dual storage mechanism facilitates subsequent business auditing and data traceability, contributing to the construction of a complete chain of evidence for task execution.

[0105] This application proposes a distributed execution scheme for blockchain task on-chain execution to address the congestion and avalanche risks associated with blockchain on-chain operations. The scheme aims to meet the timeliness and high throughput requirements of time-sensitive tasks while also satisfying system stability and reliability requirements. An example scenario diagram of this scheme is shown below. Figure 2 As shown:

[0106] The first step is to receive tasks reported by the business system and prioritize them according to the scenario. The system receives on-chain tasks from the upstream system. The task content includes on-chain hash value, on-chain batch number (generated at 0:00:00 every hour), timestamp (in minutes and seconds), and other task metadata. This invention determines the initial priority of tasks based on the task scenario and task generation time, and uses a two-dimensional approach of hierarchy and time for priority control: the hierarchy is manually specified according to the timeliness requirements of the task scenario for coarse-grained control, while the time is determined by the task generation timestamp for fine-grained adjustment.

[0107] Assuming the current task is I, the manually specified level is Ii, the on-chain batch number is bi, the task generation timestamp is ti, the corresponding number of bits for the on-chain batch number is len(bi), the corresponding number of bits for the timestamp Ti is len(ti), and the priority of task I is pi, then:

[0108] The second step is to collect blockchain node resources, on-chain task execution node resources, and on-chain task execution metrics. Each task execution node reports in real time metrics such as memory, CPU, bandwidth usage, block height, number of pending transactions on the chain, task success and failure information, and task execution time, which are ultimately stored centrally in a caching middleware or database.

[0109] The third step is to dynamically adjust the priority and on-chain speed of tasks. This involves monitoring available resource metrics per second for the current moment and the past n days, including remaining available memory m0, m1, m2, ..., mn, remaining available CPU c0, c1, c2, ..., cn, and remaining available bandwidth γ0, γ1, γ2, ..., γn. Simultaneously, task execution metrics per second for the current moment and the past n days are collected: number of pending on-chain transactions s0, s1, s2, ..., sn, task on-chain success rate p0, p1, p2, ..., pn, task on-chain time t0, t1, t2, ..., tn, on-chain block height h0, h1, h2, ..., hn, block height change rate ω0, ω1, ω2, ..., ωn, and the standard deviation of the task on-chain success rate. The space occupied by a single transaction can be obtained through statistical methods and mathematical calculations. CPU usage per transaction execution Bandwidth consumed by a single transaction execution By setting the blockchain, the maximum number of transactions within a blockchain block can be obtained as C. Then, at the current moment, the manually estimated maximum speed φ and the stable rate ρ when the cluster uploads data are respectively:

[0110]

[0111]

[0112] Among them, the function The function is for solving The minimum value.

[0113] Based on the number of task failures and the success rate ρ, a backoff mechanism is used to prioritize failed tasks, and the priority is dynamically adjusted through the time dimension. The number of failures is denoted as f, i.e.:

[0114]

[0115] The fourth step is to distribute the execution of on-chain tasks according to a priority and rate control strategy. On-chain task execution nodes acquire tasks to be executed sequentially through a weighted allocation mechanism based on different levels (higher priority levels have higher weights), and tasks are acquired from smallest to largest time dimension. Each node allocates tasks based on its remaining available memory. Remaining available CPU and remaining available bandwidth Success rate of on-chain tasks Calculate its own processing capacity limit , but .

[0116] This allows the node to obtain its real-time execution rate and execute the task. After the task is completed, the node submits the generated hash value to the blockchain network for on-chain processing and persists the task execution result to the database and cache.

[0117] Using the methods described above, the system can achieve efficient task execution, reliable result storage, and real-time status query.

[0118] and Figure 1 Corresponding to the method described herein, embodiments of this application also provide a processing device for blockchain on-chain tasks, applied to data processing nodes in a blockchain, specifically for processing... Figure 1 The specific implementation of the method is shown in the following structural diagram. Figure 3 As shown, it includes:

[0119] The receiving unit 301 is used to receive on-chain tasks reported by the business system; the on-chain task is a task to be submitted to the blockchain network by the task execution node.

[0120] The first determining unit 302 is used to determine the initial priority of the on-chain task based on the task scenario and task generation time of the on-chain task.

[0121] The acquisition unit 303 is used to acquire the current first resource status of the blockchain node, the current second resource status of the task execution node, and the task operation indicators in the blockchain network.

[0122] The second determining unit 304 is used to determine the execution priority and on-chain rate of the on-chain task based on the first resource status, the second resource status and the task operation indicators.

[0123] Control unit 305 is used to control the task execution node to execute on-chain tasks based on execution priority and on-chain rate.

[0124] In some embodiments provided in this application, optionally, the first determining unit includes:

[0125] The sub-unit is determined to determine the hierarchical priority of the task scenario based on the preset scenario timeliness requirements and hierarchical mapping relationship.

[0126] The parsing sub-unit is used to parse the metadata of the on-chain task to obtain its task generation timestamp and on-chain batch number;

[0127] The calculation subunit is used to calculate the initial priority of the on-chain task based on the hierarchical priority, the task generation timestamp, and the on-chain batch number.

[0128] In some embodiments provided in this application, optionally, the acquisition unit includes:

[0129] The sending subunit is used to send a query request to the blockchain node to obtain the first resource status of the blockchain node. The first resource status includes the block height, the number of transactions to be confirmed on the chain, and the block height change rate.

[0130] The monitoring subunit is used to monitor the task execution node and obtain the second resource status, which includes the remaining available memory, the remaining available CPU computing power, and the remaining available network bandwidth.

[0131] The data collection subunit is used to collect task execution metrics from the task execution log of the task execution node. These metrics include task on-chain success rate, task on-chain time, and number of task failures.

[0132] The specific principles and execution processes of each unit and module in the blockchain on-chain task processing device disclosed in the above-described embodiments of this application are the same as those of the blockchain on-chain task processing method disclosed in the above-described embodiments of this application. Please refer to the corresponding parts of the blockchain on-chain task processing method provided in the above-described embodiments of this application, and they will not be repeated here.

[0133] This application embodiment also provides a storage medium, which includes stored instructions, wherein the method for controlling the device where the storage medium is located to execute the above-mentioned blockchain on-chain task is provided when the instructions are executed.

[0134] This application also provides an electronic device, the structural schematic diagram of which is shown below. Figure 4As shown, it specifically includes a memory 401 and one or more instructions 402, wherein one or more instructions 402 are stored in the memory 401 and are configured to be executed by one or more processors 403 to perform the above-mentioned blockchain on-chain task processing method.

[0135] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0136] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application program, server, or storage medium executing the operation of this invention, based on the prompt message.

[0137] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0138] It is understood that the above notification and user authorization process is merely illustrative and does not constitute a limitation on the implementation of the present invention. Other methods that comply with relevant laws and regulations may also be applied to the implementation of the present invention.

[0139] It is understood that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and related provisions.

[0140] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For apparatus embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0141] Finally, it should be noted that in this paper, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0142] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0143] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0144] The above provides a detailed description of a blockchain on-chain task processing method provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for processing blockchain on-chain tasks, characterized in that, include: Receive on-chain tasks reported by the business system; the on-chain tasks are tasks to be submitted to the blockchain network by the task execution node. Based on the task scenario and task generation time of the on-chain task, the initial priority of the on-chain task is determined; Obtain the current first resource status of the blockchain nodes in the blockchain network, the current second resource status of the task execution node, and the task operation indicators; Based on the first resource status, the second resource status, and the task operation indicators, the execution priority and on-chain rate of the on-chain task are determined. The task execution node is controlled to execute the on-chain task based on the execution priority and on-chain rate.

2. The method according to claim 1, characterized in that, The determination of initial priority based on the task scenario and task generation time of the on-chain task includes: Based on the preset scenario timeliness requirements and hierarchical mapping relationship, determine the hierarchical priority corresponding to the task scenario; Parse the metadata of the on-chain task to obtain its task generation timestamp and on-chain batch number; The initial priority of the on-chain task is calculated based on the hierarchical priority, the task generation timestamp, and the on-chain batch number.

3. The method according to claim 1, characterized in that, The process of obtaining the current first resource status of the blockchain nodes in the blockchain network, the current second resource status of the task execution node, and task operation metrics includes: Send a query request to the blockchain node to obtain the first resource status of the blockchain node, the first resource status including block height, number of transactions to be confirmed on the chain, and block height change rate; Monitor the task execution node to obtain a second resource status, which includes remaining available memory, remaining available CPU computing power, and remaining available network bandwidth. The task execution metrics are collected from the task execution log of the task execution node. The task execution metrics include the task on-chain success rate, the task on-chain time, and the number of task failures.

4. The method according to claim 1, characterized in that, The step of determining the execution priority and on-chain rate of the on-chain task based on the first resource status, the second resource status, and the task operation indicators includes: Based on the current and historical states of the first and second resources, the maximum on-chain rate and the recommended on-chain rate are calculated. If the number of task failures in the task operation metrics exceeds a threshold, the initial priority of the on-chain task will be reduced. Based on the maximum on-chain rate, the recommended on-chain rate, and the reduced initial priority, the execution priority and on-chain rate of the on-chain task are determined.

5. The method according to claim 1, characterized in that, After controlling the task execution node to execute the on-chain task based on the execution priority and on-chain rate, the method further includes: After the on-chain task is successfully executed, the task execution result is encapsulated into a transaction and submitted to the blockchain network for on-chain processing, and the on-chain transaction hash is obtained. The on-chain transaction hash, task execution status, and completion timestamp are associated and stored in the business database.

6. A device for processing blockchain on-chain tasks, characterized in that, include: The receiving unit is used to receive on-chain tasks reported by the business system; the on-chain tasks are tasks to be submitted to the blockchain network by the task execution node. The first determining unit is used to determine the initial priority of the on-chain task based on the task scenario and task generation time of the on-chain task. The acquisition unit is used to acquire the current first resource status of the blockchain node in the blockchain network, the current second resource status of the task execution node, and the task operation indicators. The second determining unit is used to determine the execution priority and on-chain rate of the on-chain task based on the first resource status, the second resource status and the task operation indicators. The control unit is used to control the task execution node to execute the on-chain task based on the execution priority and on-chain rate.

7. The apparatus according to claim 6, characterized in that, The first determining unit includes: The sub-unit is determined to determine the hierarchical priority corresponding to the task scenario based on the preset scenario timeliness requirements and hierarchical mapping relationship. The parsing subunit is used to parse the metadata of the on-chain task to obtain its task generation timestamp and on-chain batch number; The calculation subunit is used to calculate the initial priority of the on-chain task based on the hierarchical priority, the task generation timestamp, and the on-chain batch number.

8. The apparatus according to claim 6, characterized in that, The acquisition unit includes: The sending subunit is used to send a query request to the blockchain node to obtain the first resource status of the blockchain node, the first resource status including block height, number of transactions to be confirmed on the chain, and block height change rate. The monitoring subunit is used to monitor the task execution node and obtain a second resource status, which includes the remaining available memory, the remaining available CPU computing power, and the remaining available network bandwidth. The data collection subunit is used to collect the task execution metrics from the task execution log of the task execution node. The task execution metrics include the task on-chain success rate, the task on-chain time, and the number of task failures.

9. A storage medium, characterized in that, The storage medium includes stored instructions, wherein, when the instructions are executed, the device containing the storage medium is controlled to perform the blockchain on-chain task processing method as described in any one of claims 1 to 5.

10. An electronic device, characterized in that, It includes a memory and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors as described in any one of claims 1 to 5.

Images