Node computing power resource allocation method based on block chain and storage medium

Abstract

The invention belongs to the technical field of blockchains, and discloses a blockchain-based node computing power resource allocation method and a storage medium, and the method comprises the steps: collecting the load data of each chain in real time through a resource propagation chain control point mechanism as a node computing power resource, screening idle resources through a smart contract, and injecting the idle resources into a hierarchical resource pool, generating a cross-chain shared pool and a metadata index; the smart contract receives each chain resource request, obtains a two-dimensional priority, generates a scheduling sequence, synchronously arbitrates resource competition, and generates a resource allocation instruction; dividing a high-computing-power verification node and a low-computing-power verification node according to node computing power, dynamically matching an encryption strategy, generating a decryption key fragment, and forming an encrypted transmission packet; a target chain consensus mechanism is adapted, a resource request format is converted, a corresponding verification strength is matched, resource transfer is executed, and a handover voucher is generated; and the intelligent contract monitors the resource use condition, rewards points on the active shared nodes, deducts contribution degrees from the hidden resource nodes, recycles resources, and updates the quota of the cross-chain shared pool.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchains, and more particularly to a node computing power resource allocation method based on a blockchain and a storage medium. BACKGROUND

[0002] With the diversified development of blockchain technology, a multi-chain coexistence pattern of public chains, alliance chains and the like is formed, and cross-chain resource sharing becomes a key requirement for improving overall efficiency. However, due to protocol differences, computing power heterogeneity and security and trust barriers between different blockchains, cross-chain resource scheduling faces many challenges, such as difficulty in coordinating resource states, lack of fairness in scheduling strategies, and lack of effective constraints on node behavior and dynamic adaptation of resource quotas, making it difficult to balance security, efficiency and fairness in the cross-chain process.

[0003] The existing technical solutions for solving the problem of cross-chain resource management have some limitations: some solutions rely on centralized intermediaries to synchronize resource states, which makes it difficult to ensure data consistency; scheduling strategies are mostly based on a single dimension (such as task urgency) for resource allocation, ignoring the historical contribution of nodes, resulting in insufficient fairness; encryption strategies are relatively simple and do not take into account the differences in node computing power, making it difficult to balance security and efficiency; resource quotas are fixed and cannot be dynamically adjusted according to node behavior and task requirements, resulting in low utilization of idle resources, and lack of effective reward and punishment mechanisms to constrain nodes from hiding resources or maliciously using resources, resulting in insufficient system robustness. SUMMARY

[0004] In order to overcome the above-mentioned defects of the prior art, in order to achieve the above-mentioned purposes, the present application provides the following technical solutions: a node computing power resource allocation method based on a blockchain, comprising:

[0005] S1: Collecting real-time load data of each chain through a resource propagation chain control point mechanism, injecting idle resources into a hierarchical resource pool through an intelligent contract, generating a cross-chain sharing pool and metadata index;

[0006] S2: Based on the cross-chain sharing pool and metadata index, the intelligent contract receives resource requests from each chain, obtains a two-dimensional priority by combining historical contribution and task urgency, generates a scheduling sequence, synchronizes resource competition arbitration, and generates a resource allocation instruction;

[0007] S3: Based on the resource allocation instruction and the scheduling sequence, dividing high-computing-power verification nodes and low-computing-power verification nodes according to node computing power, dynamically matching encryption strategies, generating decryption key fragments, forming encrypted transmission packets, and synchronously recording permission control lists;

[0008] S4: Based on the encrypted transmission package and the permission control list, adapt the target chain consensus mechanism, convert the resource request format and match the corresponding verification strength, execute the resource atomic transfer, generate the handover voucher, and synchronize the writing of the on-chain audit log;

[0009] S5: Based on the handover voucher and the on-chain audit log, the smart contract monitors the resource usage, rewards the active sharing nodes, deducts the contribution of the resource nodes that conceal resources and recovers the resources, and updates the cross-chain sharing pool quota.

[0010] Further, the generation method of the cross-chain sharing pool and the metadata index comprises:

[0011] Through the resource propagation chain control point mechanism, the resource nodes of each blockchain are connected, and the load data of each chain is collected according to the type of the blockchain;

[0012] The collected original load data is standardized and converted into a unified resource unit;

[0013] Through the smart contract, the preset chain type-idle threshold mapping rule is loaded, the standardized resource unit is screened, and the resource type in the blockchain whose resource utilization rate does not meet the corresponding chain type idle threshold is marked as idle resource that can be dispatched;

[0014] The hierarchical resource pool is divided into a real-time pool and a cache pool, the idle resources are layered and injected into the real-time pool and the cache pool according to the resource response delay, the cross-chain sharing pool is generated, and the metadata index is recorded synchronously.

[0015] Further, the generation method of the scheduling sequence comprises:

[0016] The smart contract receives the resource requests of each blockchain through the metadata index of the cross-chain sharing pool, obtains the historical contribution degree and the task urgency of each blockchain according to the historical data and the task attributes of each blockchain;

[0017] The historical contribution degree and the task urgency are integrated to obtain a two-dimensional priority and divide the task type into an emergency task and a regular task;

[0018] The initial scheduling sequence is generated in descending order of the two-dimensional priority, and the emergency task is inserted into the initial scheduling sequence to generate the final scheduling sequence.

[0019] Further, the generation method of the resource allocation instruction comprises:

[0020] The smart contract traverses the metadata index of the cross-chain sharing pool based on the scheduling sequence, groups according to the resource type, compares the resource type, the request quantity of the resource request of each blockchain, and the resource available quantity of the cross-chain sharing pool in each group, and if a group with a resource competition scenario is identified, it is marked as a competition group;

[0021] Extract the task type of the resource request in the competition group, execute the priority preemption mechanism on the resource request marked as an urgent task, and arbitrate the resource allocation of the ordinary resource request not marked as an urgent task through a historical contribution degree random matching mechanism;

[0022] When the arbitration is completed, the resource type, target chain ID of the received resource and resource allocation quantity are integrated to generate a resource allocation instruction and synchronize it to the corresponding resource node.

[0023] Further, the way of dividing high-power verification nodes and low-power verification nodes and dynamically matching encryption strategies includes:

[0024] Based on the resource allocation instruction, the resource node designated to receive or provide resources is used as a verification node participating in encryption verification;

[0025] The historical processing data and real-time computing power indicators of the verification nodes are collected through the smart contract as the basis for judging the computing power type, and then all the verification nodes are divided into high-power verification nodes and low-power verification nodes;

[0026] The dynamic encryption strategy is defined as a computing power type based on the division of the verification nodes, performing three-level encryption verification on high-power verification nodes and lightweight two-level encryption verification on low-power verification nodes;

[0027] The three-level encryption verification is defined as attribute encryption, zero-knowledge proof and hash time lock contract;

[0028] The lightweight two-level encryption verification is defined as lightweight attribute encryption and simplified zero-knowledge proof.

[0029] Further, the way of generating a decryption key segment to form an encrypted transmission package and synchronously recording a permission control list includes:

[0030] Based on the resource allocation instruction and the matched encryption strategy, the complete decryption key automatically generated by the smart contract during resource allocation is split into multiple decryption key segments, and the decryption key segments are bound with the permission validity period according to the task type;

[0031] By defining the authorization node determination standard, the verification nodes authorized to receive the decryption key segment are determined as the authorized nodes, and then the decryption key segment is safely distributed to the authorized nodes;

[0032] According to the matched encryption strategy, the resource data participating in the resource allocation is encrypted and packaged as an encrypted transmission package containing verification materials; the boundary conditions of resource access are recorded synchronously to generate a permission control list.

[0033] Further, the generation of the handover voucher includes:

[0034] Based on the encrypted transmission package and the permission control list, the resource propagation chain is queried through the target chain ID, the consensus type of the target chain is identified, and the corresponding consensus type is matched;

[0035] According to the consensus type of the target chain, the verification material is converted into a format recognizable by the target chain, and the verification rule of the corresponding format is matched;

[0036] Through the hash time lock contract, the resource atomicity is locked between the source chain and the target chain of the resource provider; after the resource is locked, the verification node of the target chain receives the encrypted transmission package and the verification material after format conversion, and performs the verification process through the verification rule of the corresponding format;

[0037] After the verification is passed, the resource ownership transfer is completed, the handover voucher containing the verification information is generated, and the on-chain audit log of the resource propagation chain is written.

[0038] Further, the way of rewarding points to the active sharing node, deducting contribution degree and recycling resources to the resource node that hides resources includes:

[0039] Through the on-chain audit log and the handover voucher of the resource propagation chain, the active reporting data and the actual state data of the resource node are collected in real time, the active reporting data and the actual state data are compared, the error interval is obtained, and the behavior baseline is obtained;

[0040] Based on the behavior baseline, the resource node is classified and determined, if the active reporting data of the resource node meets the expectation of the behavior baseline, it is determined as accurate reporting, and the point reward mechanism is executed;

[0041] If the resource node has no active reporting data or the active reporting data does not meet the expectation of the behavior baseline, it is determined as a concealment behavior, and the punishment mechanism is triggered;

[0042] All reward and punishment results are written into the on-chain audit log and allowed to be appealed.

[0043] Further, the updating way of the cross-chain sharing pool quota includes:

[0044] The smart contract starts the quota updating mechanism regularly according to the preset time period, collects the core data of the past time period from the cross-chain sharing pool and the on-chain audit log, and combines the reward and punishment result data as the adjustment basis;

[0045] From the reward and punishment result data and the core data, the task adaptation coefficient, the resource activity coefficient and the credit coefficient are extracted as the core adjustment index; according to the core adjustment index, the basic quota proportion of each chain in the cross-chain sharing pool is adjusted through the adjustment rule;

[0046] According to the resource demand and use of the emergency task, the reservation ratio of the emergency task reserved resource is dynamically adjusted, the high credit chain and the ordinary credit chain are divided through the credit coefficient, and the emergency task reserved resource is defined to be preferentially allocated from the high credit chain;

[0047] After the basic quota proportion and the reserved ratio are adjusted, the quota updating and synchronization process is executed, and in the next update, the quota adjustment effect is verified, if the expected result is achieved, the quota updating mechanism is suspended, and the current adjustment result is maintained;

[0048] If the expected result is not achieved, the quota updating mechanism is executed again in the next adjustment.

[0049] Further, the node computing power resource allocation system based on the blockchain comprises:

[0050] The cross-chain resource pooling unit: through the resource propagation chain control point mechanism, the load data of each chain is collected in real time, the idle resources are injected into the hierarchical resource pool through the intelligent contract screening, the cross-chain shared pool and the metadata index are generated;

[0051] The resource request priority allocation unit: based on the cross-chain shared pool and the metadata index, the intelligent contract receives the resource request of each chain, obtains the two-dimensional priority by combining the historical contribution degree and the task urgency, generates the scheduling sequence, synchronously arbitrates the resource competition, and generates the resource allocation instruction;

[0052] The hierarchical encryption verification unit: based on the resource allocation instruction and the scheduling sequence, the high-power verification node and the low-power verification node are divided according to the node computing power, and the encryption strategy is dynamically matched to generate the decryption key fragment, form the encrypted transmission package, and synchronously record the permission control list;

[0053] The cross-chain consensus adaptation unit: based on the encrypted transmission package and the permission control list, the target chain consensus mechanism is adapted, the resource request format is converted and the corresponding verification strength is matched, the resource atomicity transfer is executed, the handover voucher is generated, and the on-chain audit log is synchronously written;

[0054] The resource monitoring and optimization unit: based on the handover voucher and the on-chain audit log, the intelligent contract monitors the resource use, rewards the active sharing node with points, deducts the contribution degree of the resource hiding node and recovers the resource, and updates the cross-chain shared pool quota.

[0055] The technical effects and advantages of the node computing power resource allocation method and the storage medium based on the blockchain are as follows:

[0056] The present application focuses on the multi-chain resource cooperation scene, realizes the efficient scheduling, safe transmission and dynamic adaptation of cross-chain resources through the whole-process closed-loop design, and balances the resource utilization rate, fairness and safety.

[0057] Firstly, the load data of each chain is collected in real time through the resource propagation chain control point mechanism, and then the idle resources are screened and the cross-chain sharing pool and metadata index are generated, breaking the information island between different blockchains and providing a unified and reliable resource basis for cross-chain resource scheduling;

[0058] Secondly, the double-dimension priority is obtained to generate a scheduling sequence and arbitrate resource competition, which not only guarantees the reasonable rights and interests of long-term contribution nodes, but also ensures the rapid response of emergency tasks, and improves the fairness and rationality of resource scheduling;

[0059] Then, the high-power nodes and low-power nodes are divided and the encryption strategy is dynamically matched, which ensures the security of cross-chain resource transmission, adapts to the power difference of different nodes, avoids resource waste and timeout problems, and balances safety and efficiency;

[0060] Next, the multi-chain consensus mechanism is adapted to realize the compatibility of cross-chain resource transmission under different consensus mechanisms, ensuring the safety, atomicity and traceability of resource transfer;

[0061] Finally, the resource node behavior is constrained through rewards and punishments to promote the honest participation of nodes, and the quota is dynamically updated to optimize resource allocation and improve the robustness and resource utilization efficiency of the system.

[0062] The present application realizes efficient cooperation of cross-chain resources from collection, scheduling, transmission to management through the whole process design, and takes into account safety, efficiency and fairness, and is suitable for multi-chain cooperation scenarios. BRIEF DESCRIPTION OF DRAWINGS

[0063] Figure 1 It is a schematic diagram of the node power resource allocation method based on the blockchain of the present application;

[0064] Figure 2 It is a process diagram of resource competition arbitration in the node power resource allocation method based on the blockchain of the present application;

[0065] Figure 3 It is a schematic diagram of the node power resource allocation system based on the blockchain of the present application. DETAILED DESCRIPTION

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

[0067] Embodiment one

[0068] Please refer to Figure 1As shown, the node computing resource allocation method based on the blockchain in the embodiment includes:

[0069] S1: Collect each chain load data in real time through the resource propagation chain control point mechanism, inject idle resources into the hierarchical resource pool through the intelligent contract screening, generate a cross-chain shared pool and metadata index;

[0070] S2: Based on the cross-chain shared pool and metadata index, the intelligent contract receives resource requests from each chain, combines historical contribution and task urgency to obtain a two-dimensional priority, generates a scheduling sequence, synchronously arbitrates resource competition, and generates a resource allocation instruction;

[0071] S3: Based on the resource allocation instruction and the scheduling sequence, according to the node computing power, high-computing-power verification nodes and low-computing-power verification nodes are divided, and dynamic matching encryption strategies are generated. Decryption key fragments are generated to form encrypted transmission packets, and permission control lists are recorded synchronously;

[0072] S4: Based on the encrypted transmission packet and the permission control list, adapt to the target chain consensus mechanism, convert the resource request format and match the corresponding verification strength, execute the resource atomicity transfer, generate the handover voucher, and synchronously write the on-chain audit log;

[0073] S5: Based on the handover voucher and the on-chain audit log, the intelligent contract monitors the resource usage, rewards the active sharing node with points, deducts the contribution of the resource hiding node and recovers the resource, and updates the cross-chain shared pool quota.

[0074] The generation method of the cross-chain shared pool and the metadata index includes:

[0075] The resource propagation chain control point mechanism is a fusion system composed of a resource propagation chain and a control point node, which is used to break the information island between different blockchains, realize real-time collection, verification and propagation of resource status, and specifically:

[0076] The resource propagation chain is an independent alliance chain (or a special public chain), which serves as a cross-chain resource information hub and is responsible for storing resource state data, metadata index and scheduling records. This chain needs to have high throughput (such as supporting 1000+ resource state records per second) and low delay (such as block confirmation time ≤1 second) characteristics;

[0077] The control point node is a distributed node deployed on the resource propagation chain (the number needs to be > 3, and the consistency is ensured through the PBFT consensus mechanism), which mainly undertakes three major functions, including the collection function (connecting each blockchain (such as public chain, alliance chain) through a standardized interface to obtain its resource load data in real time), the verification function (verifying the legality of the collected load data (such as verifying the data signature, comparing the historical baseline, and preventing forgery)), and the propagation function (synchronizing the verified resource data to all nodes of the resource propagation chain, and updating the metadata index of the cross-chain shared pool to ensure the consistency of the resource state of the whole network);

[0078] It should be noted that the resource data refers to the actual resource content in the cross-chain shared pool that is scheduled and transmitted, that is, the specific data corresponding to the idle resources selected in each blockchain, which is the entity object of cross-chain resource transmission (for example, a transmission channel with 50 units of bandwidth, a computing capacity with 10 units of computing power). According to the resource type, it can be divided into three categories:

[0079] Computing power resource data: refers to the computing capacity carrier corresponding to idle computing power, such as idle CPU processing capacity and GPU computing power of a server, which is represented as the product of the computing time and the number of times that can be used to execute cross-chain tasks (such as 2 hours of idle computing power of an 8-core server); bandwidth resource data: refers to the transmission capacity carrier corresponding to idle bandwidth, such as the network transmission channel that is not occupied between nodes, which is represented as the product of the rate and the time that can be used for cross-chain data transmission (such as 1 hour of usage right of 100 Mbps bandwidth); storage resource data: refers to the physical and logical space corresponding to idle storage, such as the hard disk space and the shareable data (such as cold data backup, historical block fragments) in the node that are not occupied, which is represented as the product of the capacity and the time that can be used for storing cross-chain data (such as 72 hours of usage right of 100 GB storage);

[0080] Through the resource propagation chain, the load data (including computing power, bandwidth, and storage) of each chain is collected according to the type of blockchain (such as public chain, alliance chain), and the load data of different types of blockchains is different;

[0081] Specifically, due to the dispersion of resource nodes and frequent transactions of public chains (such as Ethereum, Bitcoin), the collection frequency can be set higher (such as 10 ms / time), and the block generation speed (reflecting the computing power load), the P2P real-time transmission rate (reflecting the bandwidth load), and the storage occupancy of all resource nodes (reflecting the storage load) are collected as load data;

[0082] The consortium chain (such as Hyperledger Fabric) is controllable and has stable transaction frequency, and the collection frequency can be set low (such as 50 ms / time). The load data includes the transaction throughput of the collection channel (reflecting the bandwidth load), the CPU occupancy rate of the endorsement node (the endorsement node belongs to the resource node of the consortium chain), and the chain code data storage (reflecting the storage load);

[0083] When the load fluctuation amplitude of a certain chain within a certain time (such as 5 minutes) exceeds the expectation (such as > 30%), the collection frequency is temporarily increased (such as to twice the original frequency), and the default value is restored after the load fluctuation amplitude stabilizes, thereby ensuring the balance between data real-time performance and resource consumption;

[0084] The original load data collected from each blockchain is standardized and converted into a unified resource unit;

[0085] Among them, the bandwidth type load data is standardized into a bandwidth resource unit, 1 unit = 1 Mbps (converted according to 1 MB / s ≈ 8 Mbps, and the average value (such as the average value of the last 30 seconds) is taken);

[0086] Then, according to the bandwidth resource unit, the bandwidth type load data is converted into a resource unit, for example, the P2P transmission rate of the public chain is 2 MB / s → 2 × 8 = 16 units of bandwidth resource unit; the transaction throughput of the consortium chain is 100 times per second (each transaction has an average size of 256 KB) → 100 × 256 KB / s = 25.6 MB / s → 25.6 × 8 ≈ 205 units of bandwidth resource unit;

[0087] The storage type load data is converted into a storage resource unit combined with the corresponding data retention time, 1 unit = 1 GB / 24h (i.e. 1 GB of resource storage for 1 day is counted as 1 unit);

[0088] Then, according to the storage resource unit, the storage type load data is converted into a resource unit, for example, the consortium chain storage occupies 100 GB and is retained for 30 days → 100 × 30 = 3000 units of storage resource unit; the public chain storage occupies 500 GB (permanent storage is calculated according to 365 days / year) → 500 × 365 = 182500 units of storage resource unit;

[0089] The computing power type load data is converted into a computing power resource unit, 1 unit = 1 TFLOPS (TFLOPS is the resource node computing power benchmark value, and the resource unit is converted according to the ratio of the actual computing power of the node to the resource node computing power benchmark value, such as an 8-core server with full load corresponding to 8 units);

[0090] Then, according to the computing resource unit, the computing power type load data is converted into resource units, for example, the CPU occupancy rate of 50% of the alliance chain endorsement node (such as an 8-core server) → 8 x 50% = 4 units of computing power resource units; the block generation speed of the public chain is reduced from 10 per minute to 5 per minute (the computing power is halved) → the original 20 units of computing power → 10 units of computing power resource units;

[0091] The standardized resource units are screened by loading the preset chain type-idle threshold mapping rule (i.e. the preset public chain idle threshold (such as 20%) and alliance chain idle threshold (such as 30%) according to the chain type) through the smart contract, and if the resource utilization rate (i.e. the resource utilization rate, which is equal to the ratio of the used units to the total units) of a certain type of resource unit ≤ the idle threshold of the corresponding chain type, it is determined that it does not meet the expectation and is marked as a schedulable idle resource;

[0092] The hierarchical resource pool includes a real-time pool and a cache pool, and the idle resources are further classified according to the resource response delay, and a delay threshold (such as 100ms) is set, and the resource units with a delay less than or equal to the delay threshold are injected into the real-time pool, and the resources with a delay greater than the delay threshold are injected into the cache pool;

[0093] The resource metadata (including the chain ID to which it belongs, the resource type, the remaining available duration, and the real-time state update timestamp) is recorded synchronously when it is injected, and a cross-chain shared pool and metadata index (including the resource type, the resource response delay, the chain ID, and the index value (including the resource ID list, the total available unit quantity, and the latest update time), which is used for fast query according to the resource type, the delay, and the belonging chain) are generated;

[0094] The metadata index synchronization mechanism is set to automatically update the metadata index and broadcast the index update event to the resource propagation chain for each injection of a certain number (such as 10) of resource data, to ensure the consistency of the index of each node.

[0095] The generation mode of the scheduling sequence includes:

[0096] The smart contract receives resource requests from each blockchain through the metadata index of the cross-chain shared pool, including basic information (including the request chain ID, the resource type (bandwidth / storage / computing power), the request quantity (resource units), and the task identification (i.e. the unique ID of the task)) and task attributes (task deadline, associated user list (user ID set), and task description (such as "medical data cross-chain transmission"));

[0097] The blockchain that will make a resource request is recorded as the request chain, and the smart contract verifies the legality of the resource request, specifically:

[0098] Check if the request chain is in the preset trusted chain list (preset by the resource propagation chain control point node); verify if the request signature (signed by the resource node private key of the request chain) matches the chain ID to prevent fake requests; check if the request resource type is within the available resource range of the cross-chain sharing pool (e.g., if the request is for computing power but the cross-chain sharing pool only has bandwidth resources, it is directly rejected); if the legality verification fails, reject the resource request;

[0099] According to the historical data and task attributes of each blockchain, the historical contribution degree and task urgency of each blockchain are obtained, specifically:

[0100] Based on the historical data of the request chain, the transaction frequency (the number of successful cross-chain transactions initiated by the request chain in a certain period of time (such as 30 days) (after excluding failed transactions and timeout transactions)), node online duration (cumulative online time of the resource node of the request chain in the resource propagation chain (after excluding offline period)), and cross-chain collaboration times (number of times the request chain successfully responds to other chain requests as a resource provider in a certain period of time (such as 30 days)) are extracted as contribution indicators;

[0101] Each contribution indicator is assigned a weight, and the total weight is 1, then weighted fusion is performed, and the weighted fusion result is divided by the total resource request amount in the recent period of time (such as 30 days) to obtain the historical contribution degree;

[0102] It should be noted that the total resource request amount is the number of all resource requests initiated by the request chain in the recent period of time, which is used for normalization processing to ensure that the contribution degrees of different chains are comparable;

[0103] For example, the historical contribution degree = (30% x transaction frequency + 50% x node online duration + 20% x cross-chain collaboration times) ÷ total resource request amount of the request chain in the last 30 days;

[0104] Based on the task attributes of the request chain, the timeout risk coefficient (timeout risk coefficient = (total task duration - elapsed time) ÷ total task duration, value range 0-1 (the closer to 0, the higher the timeout risk)) and the number of associated users (the number of active users directly affected by the task (such as users with on-chain operations in the last 24 hours)) are extracted as emergency indicators;

[0105] Each emergency indicator is assigned a weight, and the total weight is 1, then weighted fusion is performed, and the weighted fusion result is divided by the total task duration to obtain the task urgency;

[0106] It should be noted that the total task duration = task deadline - current time, which is used for normalization processing to avoid overestimating the urgency of long-duration tasks;

[0107] For example, the task urgency = (60% x the overtime risk coefficient + 40% x the number of associated users) ÷ the total duration of the task (in hours);

[0108] The smart contract comprehensively considers the historical contribution degree and the task urgency, and gives a weight to each of the historical contribution degree and the task urgency (by default, the weight of each is 0.5, i.e., the importance of the historical contribution degree and the task urgency is the same, and the weight can also be individually assigned according to actual conditions and expert experience), and then a two-dimensional priority is calculated by weighted fusion;

[0109] Meanwhile, an emergency task determination threshold (such as 0.8) is set, and if the task urgency is greater than or equal to the emergency task determination threshold (i.e., close to overtime or associated with a large number of users), the task is marked as an emergency task, otherwise, the task is marked as a regular task;

[0110] The initial scheduling sequence is generated in descending order of the two-dimensional priority;

[0111] The initial scheduling sequence is dynamically adjusted according to the emergency task, and the final scheduling sequence is generated. Specifically, for requests with the same priority, the task urgency is sorted again (the higher the urgency, the earlier the request), and for emergency tasks, the request is directly inserted into the front end of the scheduling sequence and marked with an emergency identifier;

[0112] The generated scheduling sequence is written into the metadata index of the cross-chain shared pool for subsequent conflict arbitration.

[0113] The generation of the resource allocation instruction includes:

[0114] The smart contract traverses the metadata index of the cross-chain shared pool based on the scheduling sequence, and identifies a resource competition scenario, i.e., the resource requests of multiple request chains are directed to the same type of the same batch of available resources, and the total resource request amount exceeds the current available amount of the resource (such as 80 units of available amount and 120 units of total request amount);

[0115] The identification logic is: grouping by resource type, comparing the resource type, the number of requests, and the available amount of resources of the cross-chain shared pool in each group, and if the total resource request amount in a group is greater than the available amount, the group is determined to be a group with a resource competition scenario, marked as a competition group, and the request chain ID, the respective request amount, and the two-dimensional priority of each request chain participating in the competition are recorded;

[0116] The resource request marked as an emergency task in the competition group is executed with a priority preemption mechanism, specifically:

[0117] The resource request amount (such as 50 units of bandwidth) of the emergency task is compared with the available amount (such as 80 units) of the cross-chain shared pool, and if the available amount is greater than or equal to the resource request amount, the required resource is directly allocated (without participating in subsequent arbitration);

[0118] If the available amount < resource request amount (e.g., 30 units available, 50 units required for an emergency task), the smart contract selects the request with the lowest double-dimension priority from non-emergency tasks in the same group, temporarily recovers the allocated resources in the order of "low first, high second" (recovery amount = emergency task resource request amount - available amount), and marks the recovered task as a resource to be supplemented (preferentially allocated after the subsequent resource pool is supplemented);

[0119] After the priority preemption is completed, the emergency preemption event (including the emergency task ID, the recovered task ID, and the recovered resource amount) is recorded in the on-chain audit log, and an on-chain notification is sent to the request chain of the recovered task;

[0120] For ordinary resource requests that are not marked as emergency tasks, the historical contribution degree random matching mechanism is used to arbitrate resource allocation, specifically:

[0121] The historical contribution degree of each request chain is used as the weight to calculate the weight proportion: request chain weight proportion = historical contribution degree of the chain ÷ sum of historical contribution degrees of all request chains in the competition group; For example, A chain contribution degree 0.6, B chain 0.4, weight proportions are 60% and 40%, respectively.

[0122] The weight proportions are used to allocate continuous intervals (range 0-1) to each request chain; for example, A chain: [0, 0.6); B chain: [0.6, 1.0].

[0123] The smart contract calls the on-chain random number generator to generate a random number between 0 and 1, and matches the generated random number with each request chain. If the random number falls into the corresponding interval, the corresponding request chain will have priority to obtain resource allocation (for example, if the random number is 0.35 and falls into the [0, 0.6) interval of A chain, A chain will have priority to obtain resource allocation).

[0124] The request amount of the matched request chain is allocated (not more than the remaining available amount); if there is still remaining resource after allocation, the process of weight interval-random number matching is repeated for the unallocated requests until the resource allocation is complete or all requests are partially allocated (the remaining resources are allocated proportionally).

[0125] If there is still resource allocation conflict after continuous arbitration (e.g., the random number falls into the same interval multiple times but there is not enough resource), the smart contract triggers the resource expansion mechanism, specifically:

[0126] The pre-set standby resource pool (i.e., pre-set emergency resources, such as 10% of the total capacity) of the cross-chain shared pool is called to supplement the available resources of the current competition group;

[0127] If the standby resource is insufficient, an alert is sent to the resource-strained propagation chain control point node to request temporary use of non-idle resources of a low-load blockchain (additional resource usage fees need to be paid, i.e., credit points, deducted from the credit points of the request chain).

[0128] When the arbitration is completed, the resource type, the blockchain ID of the receiving resource, and the number of resource allocations are integrated to generate a resource allocation instruction (instruction ID, target chain ID (requesting chain ID of the receiving resource), resource type, allocation number, source pool (real-time pool or cache pool in the hierarchical resource pool), validity period (the instruction must be executed within the validity period), two-dimensional priority label);

[0129] The resource allocation instruction is synchronously written into the metadata index of the cross-chain shared pool, and a on-chain event (containing the instruction hash) is sent to the resource node of the target chain to ensure that it can be acquired and executed in real time;

[0130] Requests that do not receive the full allocation (such as a request for 100 units receiving only 60 units) are marked as partial allocation and enter the next round of scheduling sequence to wait for supplementary allocation.

[0131] The high-computing-power verification nodes and low-computing-power verification nodes are divided, and the dynamic matching encryption strategy includes:

[0132] It should be noted that the resource allocation instruction determines "who allocates what resources", and the scheduling sequence determines "the transmission order". Before the actual cross-chain resource transmission, a "security access link" is still needed, and the core purpose is to ensure the safety, legality, and efficiency of cross-chain resource transmission;

[0133] Based on the resource allocation instruction, the specific resource nodes participating in this resource allocation (i.e., the designated receiving or providing resources participating in this cross-chain resource transmission) are used as verification nodes participating in encryption verification (i.e., the "target chain resource nodes receiving resources" (or "source chain resource nodes providing resources") specified in the resource allocation instruction, depending on the transmission direction);

[0134] The resource allocation instruction specifies which resource node of which blockchain will receive or provide resources (such as "Node A of the Ethereum public chain receiving 10 units of bandwidth"), and only these resource nodes specified by the instruction will participate in encryption verification as verification nodes. The resource nodes not involved in the allocation instruction do not need to participate in verification, avoiding meaningless computing power consumption;

[0135] The historical processing data and real-time computing power indicators of the verification nodes are collected through the smart contract as the basis for judging the computing power type;

[0136] Among them, the historical processing speed: the time-consuming records of the verification nodes performing encryption verification tasks for a certain number of times (such as 100 times) are extracted from the on-chain audit log, the abnormal values (such as > 3σ deviation values caused by network fluctuations) are removed through the 3σ criterion, and then the average value is calculated as the historical processing speed;

[0137] Real-time computing power index: real-time monitoring of the current hardware parameters and load status of the verification node through the control point node as the real-time computing power index, including hardware configuration (CPU core number (such as 8 cores, 2 cores), memory capacity) and real-time load (CPU usage, memory occupancy, taking the sliding average value of the recent period (such as 10 seconds));

[0138] Further, all verification nodes are divided into high-computing-power verification nodes and low-computing-power verification nodes, specifically:

[0139] According to the historical processing data and the real-time computing power index, the computing power judgment basis threshold of the high-computing-power verification node and the low-computing-power verification node is defined, including the processing speed threshold, the core number threshold and the CPU usage threshold;

[0140] Based on the computing power judgment basis threshold of the high-computing-power verification node, the judgment condition of the high-computing-power verification node is defined as simultaneously satisfying: historical processing speed ≤ processing speed threshold (such as 100 ms), CPU core number ≥ core number threshold (such as 8 cores), real-time CPU usage ≤ CPU usage threshold (such as 70%, ensuring redundant computing power);

[0141] Based on the computing power judgment basis threshold of the low-computing-power verification node, the judgment condition of the low-computing-power verification node is defined as simultaneously satisfying: historical processing speed > processing speed threshold (such as 500 ms), CPU core number ≤ core number threshold (such as 2 cores), real-time memory occupancy rate ≥ CPU usage threshold (such as 60%, in the case of limited resources);

[0142] For the possible boundary cases, if the historical processing data and the real-time computing power index of the verification node fall into the intermediate interval (such as 100 ms < historical processing speed ≤ 500 ms or 2 cores < CPU core number < 8 cores), the smart contract is marked as a medium-computing-power node, and the encryption strategy of the low-computing-power verification node is temporarily adopted (to avoid verification failure due to computing power fluctuations), and it is re-judged once every 5 minutes;

[0143] Defining the encryption strategy as the computing power type after dividing the verification node, performing threefold encryption verification on the high-computing-power verification node, and performing lightweight two-stage encryption verification on the low-computing-power verification node;

[0144] Defining threefold encryption verification as attribute encryption, zero-knowledge proof and hash time lock contract, specifically:

[0145] Attribute encryption (i.e., ABE attribute-based encryption): generating an access key based on the identity attributes of the verification node (such as the chain ID to which it belongs, the resource permission level), only the nodes with attribute matching can decrypt the resource data (to prevent unauthorized access);

[0146] Zero-knowledge proof: The verifier node does not need to expose the specific resource content to prove to the target chain that the resource meets the transmission requirements (such as data integrity, authority validity);

[0147] Hash time-lock contract: Set a time lock (such as 10 minutes) and a hash lock (the hash value of the resource data), and only when the target chain receiving the resource provides the correct hash value within the time limit, the ownership of the resource is released (to ensure atomic transmission);

[0148] Define lightweight two-level encryption verification as lightweight attribute encryption and simplified zero-knowledge proof, specifically:

[0149] Lightweight attribute encryption: Simplify the attribute set (only keep the chain ID and resource type, these two core attributes), reduce the algorithm consumption of key generation and decryption;

[0150] Simplified zero-knowledge proof: Reduce the proof range (only verify data integrity, not verify permission details), use a pre-computed proof template (such as a simplified version of Groth16 algorithm), and control the verification time within an acceptable range (such as 200ms) to adapt to low-power devices.

[0151] Generate decryption key fragments, form encrypted transmission packets, and synchronize the way to record the permission control list, including:

[0152] Based on the resource allocation instruction and the matching encryption strategy, the complete decryption key generated by the smart contract during resource allocation is split into multiple decryption key fragments, specifically:

[0153] The complete decryption key for encrypting the resource is a special key dynamically generated by the smart contract in each cross-chain resource transmission task. The generation logic is: the smart contract calls the random number generator on the chain, generates an unpredictable random number based on the block hash and timestamp, then combines the random number with the unique identifier of the resource transmission task (such as the transmission packet ID), and generates the complete decryption key through asymmetric encryption (such as ECC elliptic curve encryption), ensuring that the key is unique and cannot be repeated for each task;

[0154] Split the complete decryption key into multiple decryption key fragments, the number of split decryption key fragments is the number of participating verification nodes + 1 (i.e. one more backup fragment), and define that at least more than half of the decryption key fragments are needed to combine the complete decryption key (to prevent single node from leaking the key);

[0155] For example, if there are 3 verification nodes participating in the transmission, 4 decryption key fragments are generated, and at least 2 fragments are needed to restore the complete key;

[0156] According to the task type, the decryption key fragment is bound with the authority validity period, wherein the authority validity period of the decryption key fragment of the emergency task cannot be too long (such as 24 hours), and automatically expires after the time limit; the authority validity period of the regular task can be set for a long time (such as 72 hours), and can be manually renewed through the smart contract (chain payment credit points are required);

[0157] The definition of the authorized node determination standard is that it must be a matching verification node, and the node identity must have passed the identity authentication through attribute encryption in the target chain resource node receiving the resource specified in the resource allocation instruction;

[0158] The verification node that meets all the standards at the same time is determined as a verification node that has the right to receive the decryption key fragment, and is an authorized node;

[0159] Further, the decryption key fragment is securely distributed to the authorized node through a secure distribution mechanism;

[0160] The secure distribution mechanism is defined as follows: the smart contract sends a unique key fragment to each authorized node through the encrypted channel of the resource propagation chain, and the decryption key fragment is attached with a node-specific signature for preventing man-in-the-middle replacement; the authorized node needs to return a receiving confirmation message within a certain time (such as 10 seconds) after receiving, and if not confirmed, it will be resent (up to 3 times); after all the decryption key fragments are distributed, the smart contract records the key distribution log (including decryption key fragment ID, receiving node ID, and distribution time) on the chain, but does not store the decryption key fragment content (to avoid leakage on the chain);

[0161] According to the matching encryption strategy, the resource data participating in the resource allocation is encrypted, specifically:

[0162] For high-computing-power verification nodes (triple verification):

[0163] The resource original data is encrypted by attribute encryption (the key is the public key part of the complete decryption key), and only the authorized node can decrypt it; a zero-knowledge proof is generated to prove that the encrypted data comes from the idle resources of the cross-chain sharing pool (without revealing the specific content), which includes data hash value and resource metadata digest; a hash time lock contract is bound, a hash lock (SHA-256 hash value of the encrypted data) and a time lock (equal to the key validity period) are set to ensure that the target chain completes the verification within the time limit;

[0164] For low-computing-power verification nodes (double verification):

[0165] The resource data is encrypted by lightweight attribute encryption (simplified attribute set, only chain ID and resource type are retained); a simplified zero-knowledge proof is generated to only prove “data integrity” (i.e., whether the hash value matches); a pre-computed template is used to reduce computing power consumption;

[0166] The package is encrypted and transmitted, including encrypted transmission package ID, resource metadata (type, quantity, source chain ID, target chain ID), encryption result, verification material (zero-knowledge proof, hash time lock contract, hash lock, time lock), joint signature of smart contract and source chain node (i.e. the corresponding resource node on the blockchain to which the resource belongs);

[0167] Synchronize the boundary conditions of resource access, generate the permission control list, including access node range (authorized node ID list authorized to receive decryption key fragments), permission validity (consistent with the validity period of the decryption key fragments), and operation range (allowed resource use scenarios (such as "only for medical data transmission"), prohibited operations (such as "no secondary forwarding")); The permission control list is stored in the distributed storage of the resource propagation chain with the encrypted transmission package ID as the index, and the authorized nodes can obtain the list through the on-chain query interface (the node identity needs to be verified), and the unauthorized nodes can only view the list hash value (to ensure that it cannot be tampered with);

[0168] Then, the smart contract performs the final verification on the completed transmission package:

[0169] Verify the consistency of all encrypted data and resource metadata (such as whether the encrypted data size matches the resource quantity); verify the validity of the zero-knowledge proof (achieved by calling the verification algorithm on the chain); check the matching of the permission control list and the key validity (such as whether there is a validity conflict);

[0170] If the verification fails, mark the transmission package as invalid, retrigger the encryption process (up to 3 times); if it continues to fail, send an encryption exception alarm and suspend the resource transmission task.

[0171] The generation method of the handover voucher includes:

[0172] The interface nodes deployed on the resource propagation chain and the target chain are used as the protocol conversion layer to receive the encrypted transmission package and the permission control list;

[0173] Then, the chain information recorded on the resource propagation chain is queried by the target chain ID to determine the type of the target chain and match the corresponding consensus type. Specifically:

[0174] If the target chain is a PoW (Proof of Work) chain (such as Bitcoin, Ethereum PoW stage), mark its consensus type core as "computing power competition + block hash verification";

[0175] If it is a PoS (Proof of Stake) chain (such as Ethereum PoS stage, Cardano), mark its consensus type core as "stake + node signature verification";

[0176] If it is a consensus of alliance chain (such as PBFT, Raft), mark its consensus type core as "node voting + multi-signature confirmation";

[0177] According to the target chain consensus type, the verification material is converted into a format that can be recognized by the target chain, and the verification rule of the corresponding format is matched. Specifically:

[0178] For the consensus type of PoW chain, the zero-knowledge proof in the encrypted transmission package is converted into a proof of work equivalent format: a hash value matching the block difficulty of the target chain (such as SHA-256 double hash of Bitcoin) is generated, and the resource metadata is embedded in the hash calculation process, so that the hash result meets the computing power threshold of the target chain; the hash lock in the hash time lock contract parameter is retained, and the time lock is converted into the block height of the target chain (such as 10 minutes / block of the target chain, which corresponds to about 360 blocks in 24 hours);

[0179] For the consensus type of PoS chain, the zero-knowledge proof is converted into a proof of stake certificate format: the staking asset information of the receiving node in the target chain (such as the amount of staking and the duration of staking) is associated, and a conversion formula for resource receiving authority (resource receiving authority = staking rights × 0.1) is generated to ensure that the receiving node has enough rights endorsement; the transmission package signature is converted into a multi-node signature format of the target chain (such as Ed25519 signature of Cosmos), which requires at least 3 verification nodes to sign and confirm, in order to meet the consensus verification rules of PoS chain;

[0180] For the consensus type of alliance chain (such as PBFT), the zero-knowledge proof is converted into a channel transaction proposal format, including resource metadata, encrypted data hash, and source chain node certificate; a backing request is generated and defined as needing more than half of the backing nodes in the target chain to sign, in order to meet the consensus threshold of the alliance chain;

[0181] Through the hash time lock contract, the resource is atomically locked between the source chain and the target chain of the resource provider. Specifically:

[0182] In the source chain direction, the smart contract freezes the resource data to be transmitted (such as locking the use right of 50 units of bandwidth) in the source chain of the resource provider, and sets two unlocking conditions: the target chain provides the original data hash of the encrypted transmission package before the time lock expires; the verification node of the target chain provides a valid signature (proving that the resource has been legally received);

[0183] In the target chain direction, the smart contract creates a corresponding hash time lock contract in the target chain, freezes a margin equivalent to the resource in the source chain (such as the native token of the target chain), and if the source chain resource does not arrive on time, the margin is automatically returned to the target chain node, avoiding malicious locking of resources by the source chain;

[0184] After the resource is locked, the target chain's verification node receives the format-converted encrypted transmission package and verification materials, and performs the verification process through the corresponding format verification rules. Specifically, it includes legality verification and integrity verification.

[0185] Legality verification: PoW chain, verify whether the converted proof of work hash value meets the current block difficulty, and check the consistency of the hash lock and the encrypted data; PoS chain, verify whether the staking rights and interests of the receiving node meet the standard, and whether the multi-node signature meets the quantity requirement; consortium chain, verify whether the endorsement node signature exceeds half, and whether the source chain node certificate is in the trusted list;

[0186] Integrity verification: confirm the consistency of the transmitted resource data and the idle resources in the cross-chain sharing pool through zero-knowledge proof (such as quantity, type, and non-tampering);

[0187] If the verification fails, the resource transfer task is rejected, and an alarm is issued.

[0188] If the verification is passed, the target chain smart contract returns the hash lock original image and the receiving confirmation signature to the source chain, and then triggers the source chain hash time lock contract to unlock, releasing the resource ownership.

[0189] The resource data is transferred from the hierarchical resource pool of the source chain to the resource node of the target chain, completing the physical and logical delivery (such as bandwidth channel switching usage, storage data replication to the target node);

[0190] After completing the resource ownership transfer, the smart contract generates a handover voucher containing verification information, including basic information (transmission package ID, source chain ID, target chain ID, resource type and quantity), verification information (target chain verification node signature, HTLC unlock time, resource receiving confirmation hash), and status identifier (transfer success or partial success, failure, depending on the verification result);

[0191] At the same time, the handover voucher is written into the on-chain audit log of the resource propagation chain. The log is indexed according to the structure of time + chain ID, ensuring that the source chain can query the final destination and receiving status of the resource, the target chain can query the source and verification process of the resource, and the supervision node can trace the whole process, ensuring compliance.

[0192] The active sharing node is rewarded with points, and the ways to deduct the contribution of the resource node and recover the resources include:

[0193] By the on-chain audit log and handover voucher of the resource propagation chain, the active reporting data (the resource node submits the idle resource declaration form to the smart contract at a frequency of 1 hour / time, including resource type, quantity, and estimated available duration) and actual state data (the real-time load data of the resource node collected by the control point node synchronously) corresponding to the time stamp in the recent period (such as 30 days) are compared as a group of data, the single reporting error (i.e. the absolute difference between the active reporting data and the actual state data and the ratio of the actual state data) is calculated, then all single reporting errors are integrated, the abnormal values are removed by the 3σ principle, the average value of all valid single reporting errors remaining is calculated as the error interval, and the error interval is taken as the behavior baseline (needs to be rounded up to an integer, such as the error interval 6.3%, the behavior baseline is rounded up to 7%, and the integer is convenient for rule execution);

[0194] It should be noted that the error interval of the default initial behavior baseline of the whole network is 5%, and the new resource node adopts the default value of the whole network when it joins, and then calculates its exclusive behavior baseline after accumulating data for a certain period of time (such as 30 days);

[0195] Based on the behavior baseline, the resource node is classified and determined, and the core needs to focus on the idle resource reporting behavior, specifically:

[0196] If the single reporting error between the idle resource quantity in the active reporting data of the resource node and the actual quantity collected in the actual state data is ≤ the behavior baseline, the expected behavior baseline is met, it is determined that the reporting is accurate, it meets the reward conditions, and the integral reward mechanism is executed;

[0197] The execution logic of the integral reward mechanism is:

[0198] Credit integral calculation: reward integral = idle resource quantity x a, where a is a preset proportion constant, usually defaulting to 0.1, and here the reward integral is defined as 1 integral can exchange 10 minutes of resource priority use right (can be queued in the scheduling sequence);

[0199] Example: a resource node accurately reports, the idle resource quantity reported is 200 units of bandwidth, the reward integral = 200 x 0.1 = 20 integrals, which can exchange 200 minutes (3 hours and 20 minutes) of priority use right;

[0200] A node credit integral account book is preset, and the smart contract increases the corresponding integral for the resource node that accurately reports in the node credit integral account book, records the integral source (such as 20200518-accurate reporting of bandwidth resources), and sends an on-chain notice to the resource node;

[0201] The integral use rule is that the resource node can actively exchange the integral through the smart contract when making a subsequent resource request, and the integral is automatically deducted after the exchange, and the priority use right is obtained, which can be freely used within the preset effective period (such as 72 hours after the exchange);

[0202] If the resource node does not actively report data (i.e., does not report idle resources, for example, there are actually 50 units of idle computing power, but the node reports 0) or the error of the last single report is greater than the behavior baseline (i.e., does not meet the expected behavior baseline), it is determined that the behavior is concealed, the punishment condition is met, and the punishment mechanism is triggered;

[0203] The execution logic of the punishment mechanism is:

[0204] For the resource node determined to conceal the behavior, the historical contribution degree of the resource node is deducted by a certain percentage (such as 30%, then the historical contribution degree after deduction is 70% of the original historical contribution degree), thereby directly affecting the priority of subsequent resource requests;

[0205] The smart contract calculates the amount of idle resources concealed by the resource node (i.e., the difference between the actual value and the reported value), and then queries the staked assets (such as native tokens, digital certificates) of the resource node in the resource propagation chain, whose value must be ≥ the equivalent value of the concealed resources (the equivalent value can be calculated according to the cross-chain resource exchange ratio); then, lock the staked assets equivalent to the value of the concealed resources (such as 100 tokens for concealing 100 units of computing power, then lock 100 tokens), until the node supplements the report and continues for a period of time (such as 30 days) without concealing behavior, and then it can be unlocked; the recovered idle resources are re-injected into the cross-chain shared pool for other resource nodes to request use;

[0206] For all reward and punishment results, including reward results and punishment results (deducted contribution, locked staked assets, concealed resource amount), write into the on-chain audit log and publicize on the node credit public board preset in the resource propagation chain (such as publicized for 7 days) for other chains to query the node credit status;

[0207] And allow for objections, that is, when the resource node has objections to the reward and punishment results, it can submit a complaint request within a specified time (such as 24 hours) with supporting materials (such as screenshots of load data from third-party nodes), and the smart contract starts the arbitration node voting (voted by 3 propagation chain control point nodes, 2 votes above agree to revoke the reward and punishment).

[0208] The update method of the cross-chain shared pool quota includes:

[0209] The smart contract starts the quota update mechanism at a preset time period, collects the core data of the past time period from the cross-chain shared pool and the on-chain audit log, and uses the reward and punishment result data as the basis for adjustment;

[0210] The core data includes task completion rate data, resource idle rate data, and historical quota usage data.

[0211] The task completion rate data is classified and counted according to the blockchain type (public chain / consortium chain) and the task type (emergency / regular). The blockchain emergency task completion rate is equal to the ratio of the number of successfully executed emergency tasks to the total number of emergency tasks assigned by the chain. The blockchain regular task completion rate is equal to the ratio of the number of successfully executed regular tasks to the total number of regular tasks assigned by the chain.

[0212] The successful execution refers to the record of resource transmission completion and verification in the handover voucher.

[0213] The resource idle rate data is used to calculate the idle situation of the resources contributed by each chain. The idle rate of a certain type of resource in a blockchain is equal to the ratio of the amount of idle resources not allocated in the cross-chain sharing pool to the total amount of resources injected into the cross-chain sharing pool by the chain.

[0214] The amount of idle resources not allocated refers to the remaining resources of the chain in the real-time pool and the cache pool.

[0215] The historical quota usage data records the current basic quota proportion of each chain (such as 20% for public chain A and 15% for consortium chain B), the emergency task reservation proportion (such as the current 15%), and the quota usage fluctuation in the recent period (such as 7 days) (such as the actual usage rate of emergency task reserved resources).

[0216] The reward and punishment result data includes the total amount of node credit points (the sum of credit points of all resource nodes of each chain), the punishment record frequency (the number of times the nodes of the chain are punished for concealing resources in the recent period (such as 24 hours)), and the contribution adjustment result (the average remaining contribution degree of resource nodes of each chain after the reward and punishment mechanism (reflecting the long-term credit level of the chain)).

[0217] From the reward and punishment result data and the core data, the task adaptation coefficient (i.e., the weighted sum of the emergency task completion rate and the regular task completion rate, reflecting the processing capacity of the chain for tasks, with the weight biased towards emergency tasks, such as 60% x emergency task completion rate + 40% x regular task completion rate), the resource activity coefficient (i.e., (1 - bandwidth idle rate + 1 - computing power idle rate + 1 - storage idle rate) ÷ 3), reflecting the utilization efficiency of the resources contributed by the chain), and the credit coefficient (based on the reward and punishment result, i.e., (credit point total ÷ total number of resource nodes of the chain) x 0.6 + (1 - punishment record frequency ÷ total number of resource nodes of the chain) x 0.4, where 0.6 and 0.4 are weight constants, and here they are defaulted to 0.6 and 0.4, which can be adjusted according to actual conditions), are extracted as core adjustment indicators. According to the core adjustment indicators, the basic quota proportion of each chain in the cross-chain sharing pool is adjusted through adjustment rules.

[0218] The calculation method of the new basic quota proportion is: calculating the weighted ratio of the core adjustment index, then combining the original basic quota proportion and the adjustment coefficient, and multiplying the three to obtain the new basic quota proportion;

[0219] Among them, the adjustment coefficient is 1±β, and β is a preset adjustment factor, usually 0.2; in the calculation of the weighted ratio of the core adjustment index, the importance of the task adaptation coefficient is the highest, so the weight is the highest, the importance of the resource activity coefficient and the credit coefficient is equal, so the weight is equal, therefore, the default weighted ratio calculation is: task adaptation coefficient×0.4+resource activity coefficient×0.3+credit coefficient×0.3;

[0220] According to the resource demand and use of the emergency task, the reservation ratio of the emergency task reserved resource is dynamically adjusted, specifically:

[0221] The reservation ratio of the emergency task reserved resource refers to the proportion of the resources reserved in the cross-chain sharing pool for the emergency task (emergency degree≥0.8) (default 15%);

[0222] The dynamic adjustment rule is: calculate the ratio of the actual reserved resource amount used by the emergency task to the total reserved resource amount in the recent period (7 days) as the resource usage rate of the emergency task; then take the average resource demand amount of the emergency task in the recent period (such as 7 days);

[0223] If the average resource demand amount of the emergency task is greater than the current reservation ratio×total resource amount of the cross-chain sharing pool, and the usage rate exceeds the upper limit of the usage rate threshold (such as >80%, indicating that the reserved resources are not enough), then increase the reservation ratio by 5% (the highest does not exceed 20%);

[0224] If the average resource demand amount is less than the current reservation ratio×total resource amount of the cross-chain sharing pool, and the usage rate does not exceed the lower limit of the usage rate threshold (such as <50%, indicating that the reserved resources are wasted), then reduce the reservation ratio by 3% (the minimum does not decrease to 10%);

[0225] If the average resource demand amount is equal to the current reservation ratio×total resource amount of the cross-chain sharing pool, or the usage rate is between the maximum expectation and the minimum expectation (such as 50%~80%), the current ratio is kept unchanged;

[0226] The high credit chain and the ordinary credit chain are divided by the credit coefficient, that is, a credit threshold (such as 0.7) is set, and the blockchains with a credit coefficient greater than the credit threshold are divided into high credit chains, and vice versa, into ordinary credit chains;

[0227] It is defined that the emergency task reserved resource is preferentially allocated from the high credit chain to ensure the reliability of the emergency task;

[0228] If the total amount of idle resources of the high-credit chain is greater than or equal to the emergency task reservation ratio multiplied by the total resource amount of the shared pool, 100% is allocated from the high-credit chain; if not, the remaining part is allocated from the ordinary credit chain, but an additional 5% of the basic quota of the ordinary credit chain (used to encourage the chain to improve credit) needs to be deducted;

[0229] After the basic quota ratio and the reservation ratio are adjusted, the quota updating and synchronization process is performed, specifically:

[0230] The new basic quota ratio and the new emergency task reservation ratio of each chain are written into the quota configuration of the cross-chain shared pool, replacing the old values; a transition period (such as 12 hours, starting from the update time) is set, and the new and old quotas are used in parallel during the transition period (new tasks are allocated according to the new quota, and unfinished old tasks are executed according to the old quota); a quota update notification (including the new ratio, the reservation ratio, and the adjustment reason) is sent to all resource nodes, and an update announcement (retained for 7 days for inquiry) is published on the public board of the resource propagation chain;

[0231] In the next update, the effect of this quota adjustment is verified, if the overall task completion rate improves by more than 5% and the overall resource idle rate decreases by more than 5%, the adjustment is determined to be effective, and the current adjustment logic is maintained;

[0232] If the expected value is not reached (such as the idle rate increasing after the quota of a certain chain is increased), the quota updating mechanism is re-executed in the next adjustment, forming a closed-loop management.

[0233] Embodiment Two

[0234] Please refer to Figure 3 The embodiment does not describe some parts in detail, see the description of embodiment 1, a node computing resource allocation system based on a blockchain is provided, which includes:

[0235] Cross-chain resource pooling unit: through the resource propagation chain control point mechanism, real-time collection of load data of each chain is realized, idle resources are injected into a hierarchical resource pool through intelligent contract screening, a cross-chain shared pool and metadata index are generated;

[0236] Resource request priority allocation unit: based on the cross-chain shared pool and the metadata index, the intelligent contract receives resource requests from each chain, obtains a two-dimensional priority combining historical contribution and task urgency, generates a scheduling sequence, synchronously arbitrates resource competition, and generates a resource allocation instruction;

[0237] Hierarchical encryption verification unit: based on the resource allocation instruction and the scheduling sequence, high-computing verification nodes and low-computing verification nodes are divided according to node computing power, and encryption strategies are dynamically matched to generate decryption key fragments, form encrypted transmission packets, and synchronously record permission control lists;

[0238] Cross-chain consensus adaptation unit: based on the encrypted transmission package and the permission control list, the target chain consensus mechanism is adapted, the resource request format is converted and the corresponding verification strength is matched, the resource atomicity transfer is executed, the handover voucher is generated, and the on-chain audit log is written synchronously;

[0239] Resource monitoring and optimization unit: based on the handover voucher and the on-chain audit log, the smart contract monitors the resource usage, rewards the active sharing node points, deducts the contribution of the resource node and recovers the resource, and updates the cross-chain sharing pool quota.

[0240] Embodiment three

[0241] The embodiment discloses an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to realize the operation mode of the blockchain-based node computing resource allocation system provided above.

[0242] Since the electronic device introduced in the embodiment is the electronic device used to implement the resource management method for blockchain in the embodiment, based on the blockchain-based node computing resource allocation method introduced in the embodiment, those skilled in the art can understand the specific implementation of the electronic device of the embodiment and its various forms, so the electronic device how to implement the method in the embodiment will not be introduced in detail. As long as the electronic device used to implement the blockchain-based node computing resource allocation method in the embodiment is implemented by those skilled in the art, it belongs to the scope of protection of the present application.

[0243] The above formulas are dimensionless values calculated, and the formulas are obtained by collecting a large amount of data to simulate a formula of the most recent real situation, and the preset parameters and threshold values in the formula are set by those skilled in the art according to the actual situation.

[0244] The above is only the preferred embodiment of the present application, and the protection scope of the present application is not limited to the above-mentioned embodiments, and any technical solution belonging to the idea of the present application falls within the protection scope of the present application. It should be noted that for ordinary technical users in the technical field, some improvements and decorations without departing from the principle of the present application are also considered as the protection scope of the present application.

Claims

1. A blockchain-based method for allocating node computing power resources, characterized in that, Comprise: S1: Real-time collection of each chain load data through resource propagation chain control point mechanism, screening of idle resources into hierarchical resource pool through smart contract, generation of cross-chain sharing pool and metadata index; S2: Based on the cross-chain sharing pool and metadata index, the smart contract receives resource requests from each chain, combines historical contribution and task urgency to obtain a two-dimensional priority, generates a scheduling sequence, synchronously arbitrates resource competition, and generates a resource allocation instruction; S3: Based on the resource allocation instruction and the scheduling sequence, according to the node computing power, high and low computing power verification nodes are divided, and dynamic matching encryption strategy is generated, decryption key fragments are formed, and encryption transmission package is formed, and permission control list is recorded synchronously; S4: Based on the encryption transmission package and the permission control list, adapt to the target chain consensus mechanism, convert the resource request format and match the corresponding verification strength, execute the resource atomicity transfer, generate the handover voucher, and synchronously write the on-chain audit log; S5: Based on the handover voucher and the on-chain audit log, the smart contract monitors the resource usage, rewards the active sharing node with points, deducts the contribution of the resource hiding node and recovers the resource, and updates the cross-chain sharing pool quota. 2.The method of claim 1, wherein, The generation method of the cross-chain sharing pool and the metadata index comprises: Through the resource propagation chain control point mechanism, the resource nodes of each blockchain are connected, and the load data of each chain is collected according to the type of the blockchain; The collected raw load data is standardized and converted into a unified resource unit; Through the smart contract, the preset chain type-idle threshold mapping rule is loaded, the standardized resource unit is screened, and the resource type in the blockchain whose resource utilization rate does not meet the idle threshold of the corresponding chain type is marked as idle resource that can be scheduled; The hierarchical resource pool is divided into real-time pool and cache pool, the idle resources are layered into real-time pool and cache pool according to the resource response delay, the cross-chain sharing pool is generated, and the metadata index is recorded synchronously. 3.The method of claim 2, wherein, The generation method of the scheduling sequence comprises: The smart contract receives resource requests from each blockchain through the metadata index of the cross-chain sharing pool, obtains the historical contribution and task urgency of each blockchain according to the historical data and task attributes of each blockchain; The two-dimensional priority is obtained by combining the historical contribution and task urgency, and the task type is divided into emergency task and regular task; The initial scheduling sequence is generated in descending order of the two-dimensional priority, and the emergency task is inserted into the initial scheduling sequence to generate the final scheduling sequence.

4. The blockchain-based node computing resource allocation method according to claim 3, characterized in that, The generation method of the resource allocation instruction comprises: The smart contract traverses the metadata index of the cross-chain sharing pool based on the scheduling sequence, groups by resource type, compares the resource type, request quantity and resource availability of each blockchain resource request in each group, and marks the group as a competition group if a resource competition scenario is identified; The task type of the resource request in the competition group is extracted, the priority preemption mechanism is executed for the resource request marked as an emergency task, and the historical contribution is randomly matched for the ordinary resource request not marked as an emergency task to arbitrate resource allocation; When the arbitration is completed, the resource type, target chain ID and resource allocation quantity of the received resource are integrated to generate a resource allocation instruction and synchronously sent to the corresponding resource node. 5.The method of claim 4, wherein, The way of dividing high-computing-power verification nodes and low-computing-power verification nodes and dynamically matching encryption strategies comprises: Based on the resource allocation instruction, the resource node designated to receive or provide resources is taken as a verification node participating in encryption verification; The historical processing data and real-time computing power index of the verification node are collected through the smart contract as the basis for judging the computing power type, and then all the verification nodes are divided into high-computing-power verification nodes and low-computing-power verification nodes; The dynamic encryption strategy is defined as performing three-level encryption verification on the high-computing-power verification nodes and performing lightweight two-level encryption verification on the low-computing-power verification nodes according to the computing power type after the division of the verification nodes; The three-level encryption verification is defined as attribute encryption, zero-knowledge proof and hash time lock contract; The lightweight two-level encryption verification is defined as lightweight attribute encryption and simplified zero-knowledge proof. 6.The method of claim 5, wherein, The way of generating decryption key fragments, forming an encrypted transmission package and synchronously recording a permission control list comprises: Based on the resource allocation instruction and the matched encryption strategy, the complete decryption key automatically generated by the smart contract during resource allocation is split into multiple decryption key fragments, and the decryption key fragments are bound with the valid period of permission according to the type of task; By defining the authorization node judgment standard, the verification node authorized to receive the decryption key fragment is determined as the authorized node, and then the decryption key fragment is safely distributed to the authorized node; According to the matched encryption strategy, the resource data participating in the resource allocation is encrypted and encapsulated into an encrypted transmission package containing verification materials; the boundary conditions of resource access are synchronously recorded to generate a permission control list.

7. The blockchain-based node computing resource allocation method according to claim 6, characterized in that, The way of generating the handover voucher comprises: Based on the encrypted transmission package and the permission control list, the resource propagation chain is queried through the target chain ID, the consensus type of the target chain is identified and the corresponding consensus type is matched; According to the consensus type of the target chain, the verification materials are converted into a format recognizable by the target chain, and the verification rule of the corresponding format is matched; The hash time lock contract performs atomic locking of resources between the source chain of the resource provider and the target chain; after the resource is locked, the verification node of the target chain receives the encrypted transmission package and the verification materials after format conversion, and performs the verification process through the verification rule of the corresponding format; After the verification is passed, the resource ownership is transferred, the handover voucher containing the verification information is generated and written into the on-chain audit log of the resource propagation chain. 8.The method of claim 7, wherein, The way of rewarding the active sharing node and deducting the contribution degree of the resource node hiding resources comprises: Through the on-chain audit log and the handover voucher of the resource propagation chain, the active reporting data and the actual state data of the resource node are collected in real time, the active reporting data and the actual state data are compared, the error interval is obtained as the behavior baseline; Based on the behavior baseline, the resource node is classified and judged, if the active reporting data of the resource node meets the expectation of the behavior baseline, it is judged as accurate reporting, and the integral reward mechanism is executed; If the resource node has no active reporting data or the active reporting data does not meet the expectation of the behavior baseline, it is judged as a concealment behavior, and the punishment mechanism is triggered; All the reward and punishment results are written into the on-chain audit log and allowed to file an objection. 9.The method of claim 8, wherein, The way of updating the quota of the cross-chain sharing pool comprises: The smart contract starts the quota updating mechanism at a preset time period, collects core data of a past time period from a cross-chain sharing pool and an on-chain audit log, and combines reward and punishment result data as an adjustment basis; From the reward and punishment result data and the core data, a task adaptation coefficient, a resource activity coefficient and a credit coefficient are extracted as core adjustment indexes; according to the core adjustment indexes, a basic quota proportion of each chain in the cross-chain sharing pool is adjusted through an adjustment rule; According to resource demand and use of an emergency task, a reservation proportion of emergency task reserved resources is dynamically adjusted, high credit chains and ordinary credit chains are divided through the credit coefficient, and the emergency task reserved resources are defined to be preferentially allocated from the high credit chains; After the basic quota proportion and the reservation proportion are adjusted, a quota updating and synchronization process is executed, and in the next updating, an adjustment effect of this time is verified; if the adjustment effect reaches an expectation, the quota updating mechanism is suspended, and the current adjustment result is maintained; If the adjustment effect does not reach the expectation, the quota updating mechanism is re-executed in the next adjustment.

10. A storage medium, characterized by The storage medium has a computer program stored thereon, and the computer program, when executed, implements the node computing resource allocation method based on the blockchain in any one of claims 1-9.

Images