A blockchain shard-based edge computing resource auction method

Abstract

The application provides a kind of edge computing resource auction method based on blockchain sharding, receives resource and resource demand information of both sides of sale and purchase, first round of auction randomly allocates participants to transaction shard, subsequent rounds of auction dynamically allocate sellers to transaction shard based on the updated seller set of previous round through clustering algorithm, and allocate buyers to the transaction shard where there are sellers that meet their demands. Auction mechanism is independently executed in each transaction shard to determine matching buyers and sellers and matching price, and practical byzantine fault tolerance consensus is used to confirm transaction results and update global state. In the continuous auction process, participants can be dynamically replaced and historical clustering centers can be maintained to stabilize the shards. The application is suitable for dynamic bidding relationship and real-time participation environment. Under the condition that the number of blockchain nodes in each shard is constant, as the number of shards increases, the system throughput capacity improves significantly, and the system can still operate stably under the condition of continuous replacement of participants, meeting the expansion needs of large-scale edge computing market.

Description

Technical Field

[0001] This invention relates to the fields of blockchain sharding and edge computing technology, and in particular to a method for auctioning edge computing resources based on blockchain sharding. Background Technology

[0002] Edge computing (EC) effectively reduces system latency and improves real-time performance by deploying computing power closer to data sources and terminal devices, and has become an important supporting technology for applications such as connected vehicles, autonomous driving, and augmented reality. As the market continues to expand, the EC market is gradually forming an operating model centered on resource trading, in which sellers provide computing resources, buyers submit resource requirements, and resource matching and pricing are achieved through an auction mechanism.

[0003] Traditional centralized auction models suffer from problems such as price manipulation, lack of transparency, and tamperable results. Blockchain technology, with its decentralized and immutable characteristics, offers a new solution for auction execution. Currently, blockchain-based EC auction technology has been extensively researched, with related solutions including greedy matching-based resource allocation mechanisms, off-chain optimization schemes based on state channels, real auction mechanisms for multiple resource types, and two-way auction mechanisms based on smart contracts. These technologies achieve decentralized transactions to some extent, but they are typically based on non-sharded blockchain architectures, requiring all transactions to be processed through a single consensus network. As the number of participating nodes increases, consensus communication overhead increases significantly, limiting system throughput and making it difficult to meet the demands of large-scale real-time transactions.

[0004] To improve blockchain performance, existing technologies have implemented parallel transaction processing by optimizing Layer 1 architecture or introducing blockchain sharding techniques. For example, contract sharding, account partitioning, or account graph partitioning can enhance system scalability and reduce cross-shard overhead. However, these sharding strategies largely rely on pre-observable account relationships or transaction dependency graph structures. In auction scenarios, the matching relationship between buyers and sellers is dynamically formed by the bidding results and cannot be accurately determined before the auction begins, making graph-based sharding methods ill-suited to such dynamic interactive environments.

[0005] Furthermore, traditional K-means clustering relies on static datasets, requiring clustering to be performed only after all data collection is complete. This makes it difficult to adapt to the dynamic scenario of continuous participant joining and leaving in EC auctions. Therefore, achieving efficient, stable, and scalable sharded auctions in dynamic bidding relationships and real-time participation environments remains a pressing technical challenge. Summary of the Invention

[0006] In view of the above problems, the present invention is proposed to provide a blockchain sharding-based edge computing resource auction method that overcomes or at least partially solves the above problems.

[0007] This invention discloses a method for auctioning edge computing resources based on blockchain sharding, the method comprising: Receive edge computing resource information submitted by the seller and edge computing resource requirements submitted by the buyer; Verify the identities of both the seller and the buyer, and register edge computing resource information and edge computing resource requirements. In the first round of auction, buyers and sellers are randomly assigned to transaction shards in the blockchain system. In subsequent auction rounds, sellers are assigned to transaction shards based on the seller set updated in the previous round of auction using a clustering algorithm, and each buyer in the buyer set updated in the previous round of auction is assigned to a transaction shard where at least one seller satisfies the buyer's corresponding edge computing resource requirements. In each round of auction, the auction mechanism is executed independently within each transaction segment to determine the matching buyers and sellers and the matching price. The matching buyers and sellers and the matching price are then agreed upon to obtain the transaction result, which is then written into the blockchain. Update the global state based on the transaction results of all transaction shards.

[0008] Optionally, the edge computing resource information includes the types and quantities of computing resources that the seller can provide, and the seller's quotation information; the edge computing resource demand information includes the types and quantities of computing resources required by the buyer, and the buyer's bid information.

[0009] Optionally, based on the updated seller set from the previous auction, sellers are assigned to transaction shards using a clustering algorithm, including: Based on the edge computing resource information submitted by each seller in the seller set, construct the resource feature vector of each seller; Clustering is performed on the resource feature vectors of all sellers in the seller set to obtain multiple cluster centers; Each seller in the seller set is assigned to the transaction shard corresponding to the cluster center that is closest to the seller's resource feature vector.

[0010] Optionally, each buyer in the updated buyer set from the previous auction is assigned to a transaction shard where at least one seller satisfies the buyer's corresponding edge computing resource requirements, including: Based on the edge computing resource demand information of each buyer in the buyer set, construct the resource demand feature vector of each buyer; For each buyer, calculate the distance between the resource demand feature vector of each buyer and each cluster center, and sort the cluster centers according to the distance. Then, check in turn whether there is a seller in the transaction segment corresponding to each cluster center whose resource provision meets the edge computing resource demand information of the buyer. If there is, the buyer is assigned to the currently checked transaction segment.

[0011] Optionally, the matching buyer and seller and the matching price are determined, including: For each seller within a transaction segment, collect all bids from buyers for that seller and sort them in descending order to form a list of buyer bids for each seller; Compare the highest bids in each seller's buyer bid list, select the highest bid with the largest value, and select the buyer who submitted the highest bid with the largest value as the target buyer; For all sellers who have made offers to the target buyer, determine the second-best price for each seller, calculate the difference between the target buyer's offer and the second-best price of the corresponding seller, select the seller with the largest difference as the transaction seller, and match the target buyer and the transaction seller as the buyer and seller, and use the second-best price corresponding to the transaction seller as the matching price.

[0012] Optionally, for all sellers offering prices to the target buyer, a suboptimal price is determined for each seller, including: If the seller's list of buyer offers contains the second-highest bid, then the second-highest bid will be used as the second-best price. If there is no second-highest bid in the seller's list of buyer offers, the second-best price will be the seller's lowest acceptable offer plus a preset increment.

[0013] Optionally, the auction mechanism can be executed independently within each transaction segment to determine the matched buyers and sellers and the matched price, and may also include: After a pair of matches is completed, the matched buyer and seller are removed, and the steps of determining the matched buyer and seller and the matching price are repeated until there are no more matched buyers and sellers in the transaction segment.

[0014] Optionally, a consensus is reached to confirm the matched buyer and seller and the matched price to obtain the transaction result, including: Within the transaction shard, a practical Byzantine fault-tolerant consensus mechanism is used to confirm the matching of buyers and sellers and the matching price. The matching of buyers and sellers and the matching price that have reached a consensus are taken as the transaction result.

[0015] Optionally, the method further includes: In multiple consecutive auctions, the sellers and / or buyers participating in the auction are replaced according to a preset ratio; When the clustering algorithm is executed in the next round of auction, the cluster centers obtained in the previous round of auction are used as the initial cluster centers.

[0016] Optionally, the method further includes: When assigning a buyer to a transaction shard, if after traversing all transaction shards there is no seller whose resource provision meets the buyer's corresponding edge computing resource requirements, then the buyer is marked as unassigned and will not participate in the current round of auction.

[0017] This invention has the following advantages: This invention receives and verifies information on resources and resource requirements from both buyers and sellers. In the first round of auction, participants are randomly assigned to transaction shards. In subsequent rounds, sellers are dynamically assigned to transaction shards based on the updated seller set from the previous round using a clustering algorithm, and buyers are assigned to transaction shards with sellers meeting their requirements. Each transaction shard independently executes the auction mechanism, determining the matching of buyers and sellers and the matching price by constructing a bid list, selecting the highest bid, and calculating the price advantage difference. A practical Byzantine fault-tolerant consensus is used to confirm the transaction results and update the global state. During continuous auctions, dynamic replacement of participants is supported, and historical cluster centers are used to maintain shard stability. This invention solves the price manipulation and process opacity problems of traditional centralized auctions through a multi-round adaptive sharding mechanism, overcomes the performance bottlenecks of non-sharded blockchain architectures, adapts to dynamic bidding relationships and real-time participation environments, and significantly improves system throughput as the number of shards increases. It can still operate stably even with continuous participant replacement, effectively meeting the expansion needs of the large-scale edge computing market. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the system structure and operation process of the present invention. Detailed Implementation

[0019] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0020] Reference Figure 1 The system of this invention includes buyer nodes, seller nodes, a management shard (M shard), and multiple transaction shards (T shards). The blockchain system as a whole adopts a sharded architecture, including management shards and transaction shards. The management shard is responsible for global scheduling and state management, while each transaction shard acts as an independent execution unit to complete the auction and consensus confirmation within its shard. The system operation process includes key stages such as resource uploading, shard division, auction execution within the shard, and on-chain confirmation of results.

[0021] The edge computing resource auction method based on blockchain sharding of the present invention may specifically include the following steps: Step 1: Participant registration and on-chain resource information Before the auction begins, participants must register and resource information must be recorded: Seller node resource submission: Seller nodes submit their edge computing resource information to the blockchain system, including resource quantity (such as the number of GPUs, CPU cores, memory capacity, etc.) and the seller's lowest acceptable offer. The seller resource information is sent to the management shard via blockchain transactions.

[0022] Buyer node request submission: Buyer nodes submit their edge computing resource requirements to the blockchain system, including the type and amount of computing resources needed, as well as the buyer's maximum acceptable bid. The buyer's request information is also sent to the management shard via blockchain transactions.

[0023] Identity Verification and Information Registration: After receiving information submitted by both the buyer and seller, the management shard first verifies the identities of the participants, which may include security mechanisms such as digital signature verification and certificate verification. Once verification is successful, the management shard records the seller's resource information and the buyer's demand information on the blockchain.

[0024] Step 2: Multi-round adaptive sharding processing The sharding management module, acting as a global scheduling module, performs sharding operations, assigning buyers and sellers to different transaction shards: Random allocation in the first round of auction: In the first round of auctions, a random allocation strategy was adopted due to a lack of historical data. The management shard retrieves the current set of all registered sellers and buyers.

[0025] Each seller in the seller set is randomly assigned to a different transaction shard.

[0026] Each buyer in the buyer set is randomly assigned to a different transaction shard.

[0027] Record the allocation results for each participant for reference in subsequent auction rounds.

[0028] Clustering assignment in subsequent rounds: Starting from the second round of auctions, a clustering algorithm is performed based on the updated seller set from the previous round of auctions: Constructing Seller Resource Feature Vectors: Based on the seller set updated after the previous auction, the management shard extracts the edge computing resource information of each seller and constructs a weighted resource feature vector. The weighted resource feature vector can be defined as:

[0029] in, , , These represent the unit price of each resource.

[0030] Perform K-means clustering: The management shard performs K-means clustering on the weighted resource feature vectors of all sellers to obtain K cluster centers. In subsequent rounds of auction, the cluster centers obtained from the previous round are used as the initial cluster centers to maintain the stability of the sharding.

[0031] Seller Shard Allocation: For each seller, calculate the distance between its resource feature vector and each cluster center, and assign the seller to the transaction shard corresponding to the nearest cluster center.

[0032] In the i-th round of auction: (1) If it is the first round, then the shards are initialized randomly; (2) If it is a subsequent round, the K-means algorithm is run based on the seller set of the previous round; (3) Calculate the K cluster centers; (4) Assign the seller to the nearest slice:

[0033] in:

[0034] Constructing a Buyer Resource Demand Feature Vector: Based on the updated buyer set after the previous auction, the management shard extracts the edge computing resource demand information of each buyer and constructs a weighted resource demand feature vector. The buyer weighted demand feature vector can be defined as follows:

[0035] in, , , These represent the unit price of each resource.

[0036] Buyer Fragmentation Allocation: For each buyer, perform the following operations: Calculate the distance between the buyer's resource demand feature vector and each cluster center.

[0037] Sort the cluster centers in ascending order of distance to obtain an ordered list.

[0038] The system checks each cluster center sequentially to identify sellers within its corresponding transaction shard that provide sufficient resources to meet the buyer's requirements. For example, resource constraints might include: the number of GPUs provided by the seller is no less than the number of GPUs required by the buyer; the number of CPUs provided by the seller is no less than the number of CPUs required by the buyer; and the memory capacity provided by the seller is no less than the memory capacity required by the buyer.

[0039] If a seller that meets the criteria is found within a transaction segment, the buyer is assigned to that transaction segment.

[0040] If no seller meeting the conditions is found after traversing all transaction fragments, the buyer is marked as unassigned and will not participate in the current round of auction.

[0041] Participant replacement handling: In consecutive rounds of auctions, sellers and / or buyers participating in the auction are replaced according to a preset ratio. Newly joined participants need to re-authenticate and re-register their resource information, while withdrawing participants are removed from the system. When executing the clustering algorithm in the next round of auction, the cluster centers obtained from the previous round are used as the initial cluster centers to maintain the stability of the fragmentation structure.

[0042] Step 3: Execute the auction mechanism within the transaction shard. Within each transaction segment, a single-item auction mechanism is executed independently to determine the matched buyer and seller and the matched price: 1. Construct the BidList: For each seller within a transaction segment, collect all bids from buyers for that seller and sort them in descending order to form a BidList of buyer bids. The BidList can include the buyer's identifier and the corresponding bid amount.

[0043] 2. If there are still unmatched sellers and unmatched buyers in a fragment, perform the following operations: 3. Construct a list of highest bids: For each seller m within a transaction segment that has not yet been matched, collect all bids from buyers for that seller. Then the highest bid was selected. ,all Constructing the highest bid list .

[0044] 4. Select target buyers: Compare the highest bids and select the bid with the largest value. (Assume the bid was given by user n).

[0045] Determine the suboptimal price: for user n For all sellers who have submitted bids, determine the second-best price for each seller as follows: 5. If the seller has the second-highest bid in the BidList, the second-highest bid shall be used as the second-best price.

[0046] Second highest bid 6. If the seller does not have a second-highest bid in the BidList, i.e., only user n has made a bid, then the seller's lowest acceptable price plus a preset increment will be used as the second-best price.

[0047]

[0048] in This is the preset minimum increment.

[0049] 7. Calculate the price advantage difference: For each candidate seller, calculate the difference between user n's bid and the second-best price on that seller. The larger the difference, the more significant user n's competitive advantage on that seller.

[0050]

[0051] 8. Determine the seller for the transaction: Select the seller with the largest price advantage difference as the seller for the transaction. Match user n with the seller for the transaction as the buyer and seller, and use the second-best price corresponding to the seller for the transaction as the matching price, i.e., the transaction price.

[0052]

[0053] 9. Complete the matching process, pairing user n with seller. Match; the transaction price is the corresponding ; 10. Update the matching set and repeat the matching process: After completing a pair of matches, remove the matched buyer and seller from the transaction shard. Then return to step 2; otherwise, proceed to step 11.

[0054] 11. Generate a matching result set: Record all matched buyers and sellers and their corresponding matching prices in the matching result set for subsequent consensus confirmation.

[0055] Step 4: Sharding Consensus and On-Chain Result Entry Each transaction shard reaches a consensus to confirm the auction results and writes the confirmed results to the blockchain: Intra-shard consensus confirmation: Within each transaction shard, a Practical Byzantine Fault Tolerance (PBFT) consensus mechanism is used to confirm the matching of buyers and sellers and the matching price. Nodes within the transaction shard vote on the matching result set, and when a preset consensus threshold is reached, consensus is confirmed.

[0056] Transaction results are recorded on the blockchain: The agreed-upon matching results are written into the blockchain as transaction results, ensuring that they are immutable and traceable.

[0057] Results are synchronized to the management shard: Each transaction shard synchronizes its transaction results to the management shard.

[0058] Step 5: Global State Update The management shard updates the global state based on the transaction results of all transaction shards: Summarize transaction results: The management shard collects the transaction results of all transaction shards, and summarizes and integrates them.

[0059] Update participant status: Update the status of each participant based on the transaction results, for example: The seller whose transaction has been completed is marked as "allocated," and their resources cannot be reallocated within the current auction cycle.

[0060] The buyer whose transaction has been completed is marked as "satisfied," meaning their demand has been met within the current auction period.

[0061] Update the status of participants who did not win the bid, and prepare them for the next round of auction.

[0062] Prepare for the next auction: Based on the updated participant status, prepare to execute the next auction. If the auction termination conditions are met, such as reaching the maximum number of auction rounds or all requirements being met, the auction process ends; otherwise, return to step two to execute the sharding for the next auction.

[0063] As can be seen, this invention effectively solves the problems of price manipulation, process opacity, and tamperable results in traditional centralized auctions through a multi-round adaptive sharding mechanism, while overcoming the performance bottleneck of non-sharded blockchain architectures in large-scale transaction scenarios. The clustering algorithm achieves intelligent sharding based on resource feature vectors, ensuring efficient matching between buyers and sellers; the dynamic participant replacement and cluster center inheritance mechanism maintain the stability of sharding.

[0064] This invention builds a system prototype on the enterprise-grade blockchain platform FISCO BCOS and tests its performance under different shard configurations. The system throughput is compared by adjusting the number of shards. Simultaneously, in consecutive auction rounds, buyers and sellers are replaced at a preset ratio—some participants leave and new participants join—to simulate a real-world operating environment. A certain proportion of abnormal nodes is also included for security testing. The results show that, with a fixed number of blockchain nodes in each shard, the system throughput significantly improves with increasing shard count. It also maintains stable operation even with continuous participant replacement, verifying the scalability of this invention in the large-scale edge computing market.

[0065] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0066] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0067] The various embodiments in this specification are described in a related manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0068] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention are included within the scope of protection of the present invention.

Claims

1. A method for auctioning edge computing resources based on blockchain sharding, characterized in that, The method includes: Receive edge computing resource information submitted by the seller and edge computing resource requirements submitted by the buyer; Verify the identities of both the seller and the buyer, and register edge computing resource information and edge computing resource requirements. In the first round of auction, buyers and sellers are randomly assigned to transaction shards in the blockchain system. In subsequent auction rounds, sellers are assigned to transaction shards based on the seller set updated in the previous round of auction using a clustering algorithm, and each buyer in the buyer set updated in the previous round of auction is assigned to a transaction shard where at least one seller satisfies the buyer's corresponding edge computing resource requirements. In each round of auction, the auction mechanism is executed independently within each transaction segment to determine the matching buyers and sellers and the matching price. The matching buyers and sellers and the matching price are then agreed upon to obtain the transaction result, which is then written into the blockchain. Update the global state based on the transaction results of all transaction shards.

2. The method according to claim 1, characterized in that, The edge computing resource information includes the types and quantities of computing resources that the seller can provide, and the seller's quotation information. The edge computing resource demand information includes the types and quantities of computing resources required by the buyer, and the buyer's bid information.

3. The method according to claim 1, characterized in that, Based on the updated seller set from the previous auction, sellers are assigned to transaction shards using a clustering algorithm, including: Based on the edge computing resource information submitted by each seller in the seller set, construct the resource feature vector of each seller; Clustering is performed on the resource feature vectors of all sellers in the seller set to obtain multiple cluster centers; Each seller in the seller set is assigned to the transaction shard corresponding to the cluster center that is closest to the seller's resource feature vector.

4. The method according to claim 3, characterized in that, Each buyer in the updated buyer set from the previous auction will be assigned to a transaction shard where at least one seller satisfies the buyer's corresponding edge computing resource requirements, including: Based on the edge computing resource demand information of each buyer in the buyer set, construct the resource demand feature vector of each buyer; For each buyer, calculate the distance between the resource demand feature vector of each buyer and each cluster center, and sort the cluster centers according to the distance. Then, check in turn whether there is a seller in the transaction segment corresponding to each cluster center whose resource provision meets the edge computing resource demand information of the buyer. If there is, the buyer is assigned to the currently checked transaction segment.

5. The method according to claim 1, characterized in that, Determine the matching buyer and seller and the matched price, including: For each seller within a transaction segment, collect all bids from buyers for that seller and sort them in descending order to form a list of buyer bids for each seller; Compare the highest bids in each seller's buyer bid list, select the highest bid with the largest value, and select the buyer who submitted the highest bid with the largest value as the target buyer; For all sellers who have made offers to the target buyer, determine the second-best price for each seller, calculate the difference between the target buyer's offer and the second-best price of the corresponding seller, select the seller with the largest difference as the transaction seller, and match the target buyer and the transaction seller as the buyer and seller, and use the second-best price corresponding to the transaction seller as the matching price.

6. The method according to claim 5, characterized in that, For all sellers offering prices to the target buyer, determine the second-best price for each seller, including: If the seller's list of buyer offers contains the second-highest bid, then the second-highest bid will be used as the second-best price. If there is no second-highest bid in the seller's list of buyer offers, the second-best price will be the seller's lowest acceptable offer plus a preset increment.

7. The method according to claim 5, characterized in that, The auction mechanism is executed independently within each trading segment to determine the matching buyers and sellers and the matched price, and also includes: After a pair of matches is completed, the matched buyer and seller are removed, and the steps of determining the matched buyer and seller and the matching price are repeated until there are no more matched buyers and sellers in the transaction segment.

8. The method according to claim 1, characterized in that, The transaction result is obtained by reaching a consensus on the matched buyer and seller and the matched price, including: Within the transaction shard, a practical Byzantine fault-tolerant consensus mechanism is used to confirm the matching of buyers and sellers and the matching price. The matching of buyers and sellers and the matching price that have reached a consensus are taken as the transaction result.

9. The method according to claim 1, characterized in that, The method further includes: In multiple consecutive auctions, the sellers and / or buyers participating in the auction are replaced according to a preset ratio; When the clustering algorithm is executed in the next round of auction, the cluster centers obtained in the previous round of auction are used as the initial cluster centers.

10. The method according to claim 4, characterized in that, The method further includes: When assigning a buyer to a transaction shard, if after traversing all transaction shards there is no seller whose resource provision meets the buyer's corresponding edge computing resource requirements, then the buyer is marked as unassigned and will not participate in the current round of auction.

Images