Competition rights management system, method, apparatus and related equipment

Abstract

This application discloses a competition rights management system, method, apparatus, and related equipment. The system includes: a blockchain network consisting of provincial nodes deployed in various provincial-level administrative regions and core nodes deployed in the Chinese Athletics Association. The provincial nodes employ the Hyperledger Fabric framework, and the nodes interact using the Practical Byzantine Fault-Tolerant (PBFT) consensus algorithm; edge computing nodes deployed at the event site, communicating with the blockchain network, for real-time collection of athlete performance, event level, and regional difficulty coefficient data; a smart contract module deployed in the blockchain network, for determining a comprehensive score based on athlete performance, event level, and regional difficulty coefficient data, and dynamically adjusting competition rights based on the comprehensive score and preset conditions; and a competition rights allocation engine coupled to the smart contract module, for generating a competition rights allocation scheme based on the comprehensive score, host city requirements, and athlete influence data.

Description

Technical Field

[0001] This application relates to the field of communication and information systems technology, specifically to a competition rights management system, method, apparatus, and related equipment. Background Technology

[0002] With the rapid development of large-scale events such as marathons in my country, the allocation and management of entry slots has become an important and complex task. Traditional event management models face severe challenges in dealing with massive numbers of runners registering, cross-regional recognition of results, real-time anti-cheating measures, reliable data storage, and economic synergy with event venues. Building a secure, efficient, intelligent marathon entry rights management system with economic empowerment capabilities has become a key technological requirement for promoting the modernization and industrialization of sports events.

[0003] Currently, relevant technical solutions mainly include cloud-based automated scoring systems, image recognition-based smart trail interaction systems, and blockchain-based data transaction and credit assessment systems. While these solutions improve efficiency or user experience in specific areas, they generally suffer from issues such as centralized architecture, lagging data processing, and limited application scenarios. For example, cloud computing solutions rely on central servers, making it difficult to support real-time processing and low-latency responses at the event site; image recognition solutions focus on local interaction, lacking global trusted evidence storage and cross-domain collaboration capabilities; and blockchain data transaction solutions are limited to specific business scenarios and are not deeply integrated with the event management system.

[0004] The existing technologies mentioned above suffer from three main problems: First, insufficient real-time data processing and security prevent on-site localized real-time processing and immediate blockchain storage, leading to delays in results verification, slow anti-cheating responses, and risks of data tampering and leakage during transmission and storage. Second, the participation rights allocation mechanism is rigid and simplistic, relying heavily on lotteries or simple performance thresholds, failing to dynamically and personally allocate participation based on multiple factors such as event level, regional difficulty, participant influence, and urban development needs. Third, the event operation is disconnected from urban economic development; the system's functions are limited to basic aspects such as registration and results management, lacking effective support for tourism promotion, industrial linkage, and commercial empowerment in the host city, thus failing to fully realize the comprehensive economic benefits of large-scale events. These shortcomings collectively hinder the intelligent upgrading and value chain extension of marathon event management. Summary of the Invention

[0005] The purpose of this application is to overcome the shortcomings of the existing technology and provide a marathon entry rights management system, method, device and related equipment to solve the problems of lagging data processing, single allocation dimension and disconnection from urban economic needs in the current marathon entry rights management technology.

[0006] This application provides a competition rights management system, including: The blockchain network consists of provincial nodes deployed in various provincial-level administrative regions and core nodes deployed in the Chinese Athletics Association. The provincial nodes adopt the Hyperledger Fabric framework, and the nodes interact with each other through the Practical Byzantine Fault-Tolerant PBFT consensus algorithm. Edge computing nodes, deployed at the event site, communicate with the blockchain network to collect data on contestant scores, event level, and regional difficulty coefficients in real time. The smart contract module, deployed in the blockchain network, is used to determine the overall score based on the contestant's performance, the level of the competition, and the regional difficulty coefficient data, and to dynamically adjust the right to participate based on the overall score and preset conditions. The participation rights allocation engine, coupled to the smart contract module, is used to generate a participation rights allocation scheme based on the overall scores, the host city's requirements, and the contestants' influence data.

[0007] This application provides a method for managing participation rights, the method being applied to a participation rights management system, including: Real-time data collection of contestant scores, competition level, and regional difficulty coefficients is achieved through edge computing nodes; The smart contract module determines the overall score based on the contestant's performance, the level of the competition, and the regional difficulty coefficient, and dynamically adjusts the right to participate based on the overall score and preset conditions. The participation rights allocation engine generates a participation rights allocation scheme based on the overall scores, the host city's needs, and the participants' influence data.

[0008] This application also provides a competition rights management device, including: The data acquisition module is used to collect data on athletes' scores, competition level, and regional difficulty coefficient in real time through edge computing nodes; The participation rights adjustment module is used to determine the overall score based on the contestant's performance, competition level, and regional difficulty coefficient data through the smart contract module, and to dynamically adjust the participation rights based on the overall score and preset conditions. The participation rights allocation module is used to generate a participation rights allocation scheme based on the overall scores, the host city's needs, and the participants' influence data through the participation rights allocation engine.

[0009] This application also provides an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. The processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps in the competition rights management method provided in this application.

[0010] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to implement the steps in the competition rights management method provided in this application.

[0011] This application also provides a computer program product that stores instructions that, when executed by a computer, cause the computer to perform the steps in the competition rights management method provided in this application.

[0012] The beneficial effects of the embodiments of this application are as follows: The participation rights management system provided in this application constructs a blockchain network consisting of provincial nodes and core nodes, and utilizes the PBFT consensus algorithm to ensure reliable interaction between nodes. This provides an immutable and traceable foundation for evidence storage of participation rights data at the system architecture level. Simultaneously, by deploying edge computing nodes on-site, real-time collection and localized processing of core data such as contestant scores, competition levels, and regional difficulty coefficients are achieved, effectively reducing data upload latency and network dependence, and improving data processing timeliness. Furthermore, the smart contract module deployed in the blockchain network can automatically determine the overall score and dynamically adjust participation rights based on the collected multi-dimensional data. The participation rights allocation engine, by integrating multi-source information such as score data, city needs, and contestant influence, automatically generates a more adaptable allocation scheme. This significantly improves the accuracy, fairness, and execution efficiency of participation rights management while ensuring the automation and transparency of the allocation process. Attached Figure Description

[0013] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A schematic diagram of the structure of a competition rights management system provided as an exemplary embodiment of this application; Figure 2 A flowchart illustrating a competition rights management method provided for an exemplary embodiment of this application; Figure 3 A schematic diagram of the structure of a competition rights management device provided for an exemplary embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this application. Detailed Implementation

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

[0015] The following is a description of the terms used in this application: In this application embodiment, a blockchain network specifically refers to a distributed digital ledger system maintained by multiple decentralized nodes and achieving data consistency based on a consensus algorithm. Specifically, the network architecture of this application embodiment consists of provincial nodes deployed in various provincial-level administrative regions and core nodes serving as authoritative data hubs (such as the Chinese Athletics Association node). Nodes interact and synchronize data through a specific consensus mechanism (such as PBFT) to achieve trusted storage, immutability, and historical traceability of event data across the entire network.

[0016] An edge computing node refers to a computing device or unit deployed near the data source or physical location (such as a marathon event). In this embodiment, the node is directly responsible for collecting raw data (such as athlete results) from the event site in real time, performing preliminary data processing (such as encryption, compression, and verification) locally, and then uploading the results to the blockchain network via a high-speed network (such as 5G). This aims to reduce data transmission latency, alleviate the load on the central network, and improve the real-time performance and privacy of data processing.

[0017] In this embodiment of the application, a smart contract refers to a piece of programmable, automatically executing computer code deployed and running on the blockchain network. It embeds predefined business logic and rules, and can respond to external events or transactions to automatically perform a series of management functions such as verifying competition results, weighted calculations, adjusting participation rights, distributing rewards, and arbitrating disputes, without relying on the intervention of a centralized institution.

[0018] An Entry Right Allocation Engine refers to a software module that integrates data processing and decision-making logic. In this embodiment, the engine works in conjunction with a smart contract module, and its core function is to receive and comprehensively analyze information from multiple sources (including contestants' overall scores, the host city's preset economic and brand promotion needs, contestants' social influence data, etc.), and automatically generate personalized entry right allocation schemes based on preset allocation strategies and algorithms.

[0019] In this embodiment, the composite score refers to a numerical value that is normalized and evaluated based on a quantitative algorithm for a competitor's performance in different competitions. Its calculation process integrates competition level weights (different importance coefficients assigned according to the competition's certification level) and regional difficulty coefficients (dynamically adjusted coefficients reflecting the objective difficulty level of the competition's location, such as terrain and climate). It aims to objectively and fairly measure and compare competitors' performance in cross-regional and cross-level competitions, and is one of the core bases for allocating participation rights.

[0020] Event Level Weight refers to a pre-defined quantitative coefficient used to identify the importance and competitive level of different types of marathon events. In the embodiments of this application, event levels are typically classified according to international or domestic official certification standards (such as IAAF Gold Label events, domestic Class A events, etc.), and corresponding weight values ​​(such as 1.5, 1.2, etc.) are assigned. This weight is used to differentiate the weighting of the raw results of different event levels when calculating the athletes' overall scores.

[0021] The Regional Difficulty Coefficient is a dynamically adjusted numerical parameter used to quantify the impact of the natural environment of a marathon venue on the performance of participants. In this embodiment, the coefficient is calculated using a pre-defined evaluation model (such as a machine learning model) based on various objective environmental data such as the terrain, altitude, and climate of the event venue. It is used as an adjustment factor when calculating the overall performance of participants to eliminate the impact of regional differences on the fairness of the results.

[0022] In this embodiment of the application, "Economic Promotion Demand" specifically refers to a series of specific goals and strategies proposed by the host city of a marathon event or its management agency, aimed at boosting local tourism, consumption, commerce, and industrial development through the operation of the event. These demands are quantified and encoded as input parameters recognizable by smart contracts and allocation engines, such as providing tourism discounts to specific customer groups or inviting key opinion leaders to participate to enhance brand exposure, and directly influence the generation of the participation rights allocation scheme.

[0023] As described in the background section, marathon entry rights management primarily employs the following technical approaches: Cloud-based competition management systems, such as the intelligent competition scoring system proposed in CN116029875B, integrate functions such as contestant authentication, answer monitoring, automated scoring, and anti-cheating detection. By centrally processing competition data in the cloud, it improves scoring efficiency and fairness. However, this system relies on cloud computing and storage, resulting in problems such as large data transmission latency and insufficient real-time processing capabilities. Especially in competition venues with poor network environments, it is difficult to guarantee the immediacy and stability of data processing.

[0024] Image recognition-based smart trail systems, such as the seamless smart trail running system proposed in CN116805432B, utilize cameras to capture runner images and achieve identity recognition and personalized interaction through technologies such as facial recognition and gait analysis. While this system enhances the running experience, its technical architecture focuses on local image processing and lacks global data accessibility, reliable data storage, and cross-regional collaboration capabilities, making it difficult to support large-scale, multi-site marathon event management.

[0025] Blockchain-based data trading and reward systems, such as the blockchain-based data distribution and processing method proposed in CN117436853A, use smart contracts to assess the creditworthiness of electricity data providers and buyers and automatically distribute token rewards. This solution demonstrates the advantages of blockchain in data ownership confirmation and automatic execution, but its application is limited to energy data trading and has not been extended to the field of sports event management. Furthermore, it does not incorporate edge computing to support real-time, localized data processing.

[0026] Despite the advancements in various aspects of these technologies, they still have significant shortcomings in the specific scenario of marathon entry management: (1) Insufficient real-time performance and security of data processing: Existing systems mostly rely on centralized cloud processing, and data needs to be transmitted over long distances to the central server, resulting in processing delays and making it difficult to meet the needs of on-site event for real-time verification of results and immediate monitoring of abnormal behavior. Data faces the risk of leakage and tampering during transmission and storage, and lacks effective encryption and tamper-proof mechanisms, which affects the credibility of the event.

[0027] (2) The participation rights allocation mechanism is simplistic and lacks multi-dimensional coordination: Traditional allocation methods are mostly based on lotteries or historical results, failing to comprehensively consider multi-dimensional factors such as the level of the competition, regional difficulty, the influence of the participants, and the economic needs of the host city. There is a lack of dynamic adjustment mechanism, making it impossible to flexibly adjust the participation rights allocation strategy according to the progress of the competition and the needs of city promotion.

[0028] (3) Lack of effective empowerment of the host city's economy and brand: The existing system focuses on the operation of the event itself and fails to deeply integrate with urban tourism, commercial promotion and industrial linkage, so the economic driving effect of the event on the host city is limited. It lacks data-driven functions such as urban service recommendation and industrial demand forecasting, making it difficult to systematically improve the overall benefits of the event.

[0029] (4) Weak system scalability and cross-regional collaboration: The traditional architecture is difficult to support data exchange and mutual recognition of results among multiple provinces and events, which hinders the establishment of a unified national event results management system. The lack of standardized and scalable technical protocols limits the promotion and application of technology in various sports events.

[0030] In recent years, blockchain technology and edge computing have developed rapidly and are gradually being applied in fields such as the Internet of Things, supply chain, and digital identity. Blockchain, with its decentralized, immutable, and traceable characteristics, provides a foundation for trusted data storage and automated contract execution; edge computing, by processing data in real time at its source, significantly reduces transmission latency and improves system response speed and privacy protection. Combining the two to build a cloud-edge-device collaborative distributed management architecture has become an important technological direction for solving the aforementioned problems.

[0031] However, there is currently no systematic solution that deeply integrates blockchain and edge computing specifically for marathon entry rights management. How to design a distributed node architecture for race scenarios, how to achieve real-time data collection and secure on-chain recording, how to build a smart contract-driven multi-dimensional entry rights allocation engine, and how to empower the host city's economic development through data remain key technological gaps that urgently need to be addressed.

[0032] This application provides a competition rights management system. It constructs a blockchain network consisting of provincial nodes and core nodes, and utilizes the PBFT consensus algorithm to ensure reliable interaction between nodes. Simultaneously, by deploying edge computing nodes on-site, it achieves real-time collection and localized processing of core data such as contestant scores, competition level, and regional difficulty coefficients. Furthermore, the smart contract module deployed in the blockchain network can automatically determine the overall score and dynamically adjust competition rights based on the collected multi-dimensional data. The competition rights allocation engine automatically generates a more adaptable allocation scheme by integrating multi-source information such as score data, city needs, and contestant influence.

[0033] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0034] Figure 1 This is a schematic diagram of the structure of a competition rights management system provided as an exemplary embodiment of this application. Figure 1 As shown, the system 100 includes: The blockchain network consists of provincial nodes deployed in various provincial-level administrative regions and core nodes deployed in the Chinese Athletics Association. The provincial nodes adopt the Hyperledger Fabric framework, and the nodes interact with each other through the Practical Byzantine Fault-Tolerant PBFT consensus algorithm. Edge computing nodes, deployed at the event site, communicate and connect with the blockchain network to collect data on athletes' scores, event level, and regional difficulty coefficients in real time. The smart contract module, deployed on the blockchain network, is used to determine the overall score based on the contestant's performance, the level of the competition, and the regional difficulty coefficient data, and to dynamically adjust the right to participate based on the overall score and preset conditions. The participation rights allocation engine, coupled with the smart contract module, is used to generate participation rights allocation schemes based on overall scores, host city requirements, and participant influence data.

[0035] In this application embodiment, the term "blockchain network," as defined above, specifically refers to a distributed system composed of provincial nodes and core nodes. Provincial-level administrative region nodes (hereinafter referred to as provincial nodes): These are blockchain nodes deployed within the administrative region of a specific province (autonomous region, or municipality). These nodes not only serve as authoritative evidence storage and query portals for event data within the region, but also undertake consensus and synchronization tasks with peer nodes and core nodes. They utilize the enterprise-grade blockchain framework Hyperledger Fabric, a permissioned blockchain platform that supports channel isolation and modular architecture, suitable for multi-party collaborative business scenarios requiring clearly defined node identities and permissions.

[0036] The Chinese Athletics Association Core Node (hereinafter referred to as the Core Node) refers to the centralized authoritative node deployed and maintained by the Chinese Athletics Association (or a similar national-level sports management organization). Its main function is to serve as the final anchor point for all network data, formulate and maintain unified competition standards and rules, and be responsible for the global consistency synchronization and arbitration of cross-provincial data.

[0037] PBFT consensus algorithm: Practical Byzantine Fault Tolerance consensus mechanism. In this blockchain network, by running this algorithm, each node can reach a consensus on transaction order and data state even if some nodes (no more than 1 / 3 of the total number) fail or act maliciously. This ensures that the event data written to the blockchain is consistent, immutable, and final across the entire network, meeting the high requirements of event management for data trustworthiness.

[0038] In actual deployment, provincial sports authorities or designated technical units are responsible for operating and maintaining provincial nodes and accessing event data within their respective provinces. All provincial nodes, together with the core nodes of the Chinese Athletics Association, form a consortium blockchain network. When new event results data (such as encrypted data packets from edge nodes) needs to be uploaded to the blockchain, it is first submitted to the provincial node of the province to which it belongs. This provincial node, acting as a proposal node, broadcasts the transaction proposal containing the data to all other nodes (including other provincial nodes and the core node). All nodes independently execute simulated transactions (such as calling smart contracts for verification) and conduct multiple rounds of voting on the hash value of the execution result. When more than 2 / 3 of the nodes (including the core node) have received valid signature confirmation, the transaction, along with its execution result, is encapsulated into a new block and appended to the local blockchain ledger of each node, completing the trusted storage of the data. The core node periodically (e.g., hourly) actively pulls new block data from each provincial node, verifies and merges it to ensure that it has a complete and up-to-date data view of the entire network.

[0039] To facilitate understanding of the consensus process, a simplified scenario is used as an example: Suppose that in a provincial marathon, an edge computing node deployed at the finish line collects a batch of runners' finishing data, encrypts and compresses it, and sends it to the provincial blockchain node (let's call it node A). Node A, acting as the proposer, packages this data into a new transaction proposal and broadcasts it to other consensus nodes in the network, including another provincial node (node ​​B), a third provincial node (node ​​C), and the core node of the Chinese Athletics Association. Subsequently, each node enters the three-phase protocol of PBFT consensus: 1. Pre-Prepare: Node A sends a pre-prepare message to other nodes. 2. Prepare: After verifying the validity of the proposal format, signature, etc., nodes B, C, and the core node each broadcast a prepare message to the entire network, indicating that they have received and agreed to the proposal. 3. Commit: Once node A receives at least 2f+1 valid preparation messages (where f is the tolerable number of faulty nodes) from other nodes (including itself) (in this example, assuming node C did not respond due to a temporary network failure, but nodes A, B, and the core node have all agreed, satisfying the condition), the proposal can be considered to have achieved consensus in the preparation phase, and then a commit message is broadcast. Finally, once a node receives enough commit messages, it officially writes this transaction into its local blockchain ledger, forming a new, immutable block. Afterward, the core node periodically synchronizes this new block from nodes A, B, etc., ensuring the integrity and consistency of the national-level data view. This example illustrates the core process from data generation to achieving consensus and permanent storage across the entire network.

[0040] For edge computing nodes, the "race site" specifically refers to key physical locations such as the start / finish line, timing points, and aid stations in a marathon. In this embodiment, edge computing nodes are typically deployed near timing chip readers, mobile timing vehicles, or on-site servers.

[0041] Real-time acquisition refers to capturing and reading data within a very short time (e.g., milliseconds) after its generation. For example, at the moment an athlete crosses the finish line, the timing system generates raw time data, and edge nodes immediately capture this data through a dedicated interface (such as a serial port or API).

[0042] Competition level and regional difficulty coefficient: As mentioned earlier, the competition level is a predefined classification label (such as the international gold label), which the edge node reads from the competition configuration file; the regional difficulty coefficient can be a pre-calculated and distributed static value, or it can be fine-tuned by the edge node based on real-time local sensor data (such as thermometers, hygrometers, barometers) through a simplified local model.

[0043] An edge computing node can physically be a ruggedized industrial computer or a high-performance embedded device. Its workflow is as follows: Step 1: Real-time reading of the contestant's segmented and total times via a connected timing device or sensor interface, forming the raw data for the contestant's scores. Step 2: Loading the current event level information (e.g., "Domestic Category A") and its corresponding weight (e.g., 1.2) from the local configuration library. Step 3: Combining the event's host city information, reading the basic regional difficulty coefficient from a pre-set difficulty coefficient table, and optionally accessing local weather station data to dynamically fine-tune the coefficient (e.g., increasing the coefficient if the current temperature exceeds a threshold). Step 4: Packaging the three core data points—contestant scores, event level, and regional difficulty coefficient—along with metadata such as timestamps and contestant IDs, into a single data packet. Step 5: Encrypting the data packet using an asymmetric encryption algorithm (e.g., RSA) and reducing the data size using a compression algorithm (e.g., gzip). Step Six: Through the high-speed, low-latency connection established by the 5G CPE (Customer Front-End Equipment) deployed on-site, the encrypted and compressed data packets are transmitted to the provincial blockchain node of its administrative region.

[0044] For example, the edge computing node's local cache can pre-store the complete rules of the current event (such as cut-off times for each segment and aid station locations), as well as the basic information and best historical scores of registered participants. Thus, when a brief communication interruption occurs at the event site due to network congestion or a malfunction, staff at the check-in or information desk can still use a handheld terminal connected to the edge node to enter the participant's race number to instantly and offline query information such as the participant's eligibility status, personal best (PB), and estimated completion time range based on historical data. This localized caching and query mechanism effectively ensures the continuity of event site management, services, and emergency response, reducing absolute dependence on the stability of the central network.

[0045] For the smart contract module, determining the overall score involves a calculation process, the core of which is performing weighted operations. Specifically, the smart contract receives the contestant's score, the competition level weight, and the regional difficulty coefficient from the edge computing node. The contract multiplies these three factors according to a preset algorithm to obtain the effective score contribution value for that competition. When calculating a contestant's overall score, the contract iterates through all of the contestant's historical on-chain competition records, performs the above multiplication operation on each record, and sums all the results to obtain a quantified total score representing their long-term, cross-regional, and cross-level performance.

[0046] Preset conditions: These refer to the set of rules written in the smart contract used to determine and trigger changes in the status of participation rights. These conditions are deterministic and include, but are not limited to, performance thresholds (such as a total score ≥ 600 points), time conditions (such as the registration deadline), eligibility status (such as whether the participant has been banned), and specific strategy instructions from the participation rights allocation engine.

[0047] Dynamic adjustment of participation rights: This refers to the smart contract automatically executing a series of state change operations based on the latest on-chain performance data (causing changes in the overall score) or preset conditions triggered by external factors (such as the host city updating its requirements). For example, when a contestant completes a new high-weighted competition and records it on the blockchain, the contract recalculates their overall score. If the new score allows them to reach the threshold for a certain high-level competition, their eligibility to participate in that competition is automatically unlocked in their digital identity.

[0048] The smart contract module in this embodiment consists of a set of contract code written in a specific on-chain programming language (such as Chaincode in Hyperledger Fabric or Solidity in Ethereum). Its execution flow is closely linked to blockchain transactions. When a data packet uploaded by an edge computing node is successfully uploaded to the chain after consensus, a specific performance verification contract is triggered. This contract first verifies the integrity and source signature of the data packet, and then parses out data such as performance scores. Next, a comprehensive performance calculation contract is called, which: 1. Queries the corresponding fixed weight based on the competition level code. 2. Calculates the weighted score for this competition by combining the regional difficulty coefficient with the contestant's original score. 3. Reads the contestant's historical comprehensive score from the chain, adds it to the current weighted score, updates the latest comprehensive score, and writes it to the on-chain state database. Subsequently, a participation rights status management contract is automatically or periodically triggered. It reads the contestant's latest comprehensive score and compares it with the preset conditions for each competition on the chain. If the conditions are met (e.g., the overall score exceeds a certain threshold), the contract will issue a qualifying token (which can be an NFT) for the corresponding event to the contestant's on-chain account (or digital certificate). The entire process is executed automatically by the blockchain network, and the results (such as the new overall score and the record of the token issuance) are permanently recorded on the blockchain and cannot be denied.

[0049] In terms of extended applications, the smart contract module can also realize automatic reward distribution and dispute arbitration functions.

[0050] Example of reward distribution: When athlete D successfully crosses the finish line, the raw signal of their crossing the timing mat is captured, verified, and encrypted on the blockchain by an edge computing node. The on-chain "Result Verification and Reward Contract" is triggered. After confirming that the result is valid and without anomalies, subsequent actions are automatically executed: First, a predetermined amount of finisher's bonus (e.g., in digital RMB) is transferred to athlete D's pre-registered and on-chain-linked digital wallet address; second, an electronic certificate generation service is invoked to create an electronic finisher's certificate with a unique blockchain transaction hash as an anti-counterfeiting identifier, and sent to athlete D's registered email address. The entire process requires no manual operation by finance personnel or staff.

[0051] Example of Dispute Arbitration: If contestant E disagrees with their split score at a certain timing point during the competition, they can submit a review application through the official event application. This application triggers a "dispute arbitration smart contract" on the blockchain as a transaction. The contract automatically executes the following process: 1. Retrieve Evidence: Retrieve the original sensor data collected at that timing point (such as the precise sensing timestamp of the RFID chip), data from adjacent timing points, and contestant E's identity binding information from the blockchain. 2. Logic Verification: Run pre-set verification logic (such as checking the continuity of timing, device ID consistency, etc.). 3. Ruling and Recording: Based on the verification results, the contract automatically makes a ruling (such as "the score is accurate, maintain the original result" or "the data is questionable, it is recommended to handle it according to rule Y"), and records a detailed record containing the complete ruling basis, logical process, and final conclusion in a new blockchain block. 4. Notification Feedback: The arbitration result is immediately fed back to contestant E through the application. The entire process is automatically executed by code, with rules pre-defined, eliminating human intervention and ensuring the efficiency, consistency, and transparency of arbitration.

[0052] For the entry allocation engine, the host city requirements refer to the economic and social goals that the event organizer (city) hopes to achieve through the marathon, beyond the competition itself. These requirements are structured and input into the engine, such as: the number of tourists from specific source areas (e.g., inland provinces) to be attracted, the type of sponsors or companies expected to cooperate, and the criteria for key opinion leaders (KOLs) with social influence to be invited.

[0053] Athlete influence data refers to metrics used to quantify an athlete's social influence and appeal, particularly within the running community. Its primary source is publicly available social media platform APIs, with the core metric being the number of followers, and it can be extended to include engagement rates, content quality ratings, and more.

[0054] Generating a participation rights allocation scheme: This is a decision-making and output process. Based on the objective comprehensive performance data provided by the smart contract module, the engine combines this with the subjective strategic guidance of the host city's needs and considers the dissemination value of contestant influence data. It then runs a built-in multi-objective optimization or rule-matching algorithm to generate a specific allocation result list for a batch of registered contestants. This scheme not only includes pass / fail conclusions but may also include different types of benefits such as direct entry, waiting list status, and qualifications with accompanying travel discounts.

[0055] The entry allocation engine typically runs as one (or a set of) server-side applications outside the blockchain network, interacting with on-chain data through the blockchain node's API interface. Its workflow is usually synchronized with the event registration period: Step 1 (Data Input): During the registration phase, the engine queries the blockchain for the overall on-chain performance of all registered participants. Simultaneously, it retrieves the specific host city requirements from the management backend (e.g., allocating at least 100 slots with scenic spot packages to participants from provinces A, B, and C; inviting 10 running KOLs with over 500,000 followers to participate for free). Furthermore, the engine calls social media platform APIs through authorized interfaces to batch obtain influence metrics such as the number of followers of registered participants. Step 2 (Solution Generation): The engine executes the core allocation algorithm. The algorithm first ensures that the hard performance threshold is met. Then, among the qualified participants, it filters and matches them according to the city requirements: for example, first filtering participants from provinces A, B, and C, ranking them by overall performance, and allocating the top 100 with attached benefits; among all remaining qualified participants, identifying the top 10 with the most followers and allocating them free entry slots. For the remaining slots, they will be allocated among the remaining qualified participants based on their overall scores. Step 3 (Solution On-Chain and Execution): The engine submits the generated final allocation scheme (participant ID-qualification type mapping table) to the blockchain network as a transaction. A dedicated allocation execution contract is triggered. After verifying the submitter's permissions, this contract mints or activates the corresponding type of participation qualification token in the on-chain account of each qualified participant according to the scheme list. The entire process, from raw data input to final token generation, is recorded on-chain and is publicly auditable.

[0056] As a concrete example, let's illustrate the complete process of the participation rights allocation engine working in conjunction with smart contracts: Suppose athlete B submits an application to participate in an IAAF Gold Label event. First, the registration action triggers the on-chain "preliminary qualification review smart contract." This contract automatically queries the blockchain and finds that athlete B's current overall score is 650 points, higher than the event's preset threshold of 600 points, thus passing the basic qualification filter. Subsequently, the list of athletes who pass the preliminary review is pushed to the off-chain participation rights allocation engine. The engine reads the economic promotion requirements set by the event organizing committee, such as: "Provide 'direct access to brand promotion' to 20 running enthusiasts with over 500,000 social media followers" and "Provide 'tourism consumption discounts' to 50 athletes from inland provinces." The engine retrieves athlete B's on-chain and related data and finds that his social media followers number 600,000 (meeting the "high influence" condition), and his place of origin is Sichuan Province (an inland region). Next, the engine runs a decision-making algorithm based on built-in priority and compatibility rules to generate a personalized allocation plan for contestant B: granting him "free direct entry to the competition" (corresponding to brand promotion needs), and simultaneously binding a "20% discount coupon for tickets to the seaside scenic area where the event is held" (corresponding to tourism consumption needs) to his electronic participation rights package. Finally, the plan is submitted back to the blockchain network for final review and execution by the "empowered execution smart contract." After the contract verification is successful, an NFT participation certificate carrying the above two rights is automatically minted and issued to contestant B's on-chain digital identity account. The entire process achieves full-chain automation and transparency from automatic review and strategy matching to rights distribution.

[0057] In some exemplary embodiments, edge computing nodes are deployed at the marathon event site and communicate with provincial nodes in the blockchain network via a 5G network to encrypt and compress the collected athlete results, event level, and regional difficulty coefficient data, and to perform preliminary verification of athlete results.

[0058] In this embodiment of the application, 5G network refers to the fifth-generation mobile communication technology network. It is applied at the event venue to provide high-bandwidth (eMBB), low-latency (URLLC), and highly reliable wireless communication connections between edge computing nodes and remote provincial blockchain nodes. Compared to traditional 4G or Wi-Fi, 5G ensures the real-time, stable, and high-speed transmission of massive amounts of event data (especially multiple high-definition video streams and a large amount of sensor data), making it a key communication infrastructure for enabling real-time data acquisition and interaction.

[0059] Encryption processing: Specifically, this refers to the process of transforming plaintext data using cryptographic algorithms before data transmission, ensuring that even if intercepted during transmission, it cannot be deciphered by an unauthorized third party. In this application embodiment, asymmetric encryption technology is preferably used. Specifically, the edge node uses the public key of the receiver (provincial blockchain node) to encrypt the data, forming ciphertext. Only the provincial node with the corresponding private key can decrypt the ciphertext, thereby achieving secure data transmission on the public network and meeting the privacy protection requirements for sensitive information such as competition results.

[0060] Compression processing refers to the process of reducing the storage space or transmission bandwidth occupied by data through specific algorithms without losing information. In the embodiments of this application, after encryption, the edge nodes apply lossless compression algorithms such as LZ77 and Huffman coding to the data packets to reduce network transmission load, further shorten upload latency, and improve the overall data transmission efficiency of the system.

[0061] For example, the core data processing flow of edge computing nodes at an event site may include: Step 1: Data Acquisition and Aggregation: Edge computing nodes, through their integrated multiple interfaces (such as RJ45, serial port, USB, or dedicated acquisition cards), access data streams in real time from the event timing system (such as RFID carpet timers, chip readers), environmental monitoring sensors (such as temperature and humidity sensors, PM2.5 sensors), and the event management system. It captures athlete scores (including segmented times and total times accurate to milliseconds), the current event level identifier, and regional difficulty coefficients dynamically calculated based on local sensor data or pre-loaded from the central system from these sources in real time.

[0062] Step 2: Data preprocessing, which may include: (1) Preliminary verification: The edge nodes first perform logical and range verification on the original performance data. For example, they check whether the segment time is positive, whether the sum of each segment matches the total time, and whether the athlete's speed is within the human physiological limit (such as whether there is abnormal data that exceeds the world record by several times). This step can filter out obvious equipment failure data or abnormal values ​​in the first place, reduce invalid data on the chain, and reduce the processing burden of the blockchain network.

[0063] (2) Encryption operation: After the verification is successful, the node packages the verification mark, the original data and the metadata. Then, it calls the built-in encryption library and uses the pre-configured RSA public key of the target provincial blockchain node to encrypt the entire data packet.

[0064] (3) Compression operation: The encrypted data packet (ciphertext) is usually larger in size. Then, the node calls a compression algorithm library (such as Zlib) to compress the ciphertext data and generate a smaller data file ready for transmission.

[0065] Step 3: Secure Transmission: The processed data file is transmitted via the node's built-in 5G module, through the operator's 5G network, in the form of IP packets to the designated provincial blockchain node's network access address. The transmission process may further enable Transport Layer Security (TLS) protocol to provide additional encryption and integrity protection for the communication link.

[0066] The core function of edge computing nodes lies in enabling localized real-time data processing and secure front-end deployment. Their real-time data processing capabilities are reflected in the initial verification and feature extraction of athlete scores (such as calculating real-time pace). The localized caching function supports storing competition rules, allowing for local queries even when the network is offline. This application's embodiment focuses on the key aspects of its interaction with the blockchain: secure communication and data preparation. After the edge node completes data encryption (edge ​​node (athlete scores)), the data can be transmitted to the provincial node via 5G (encrypted data). This completes the processing chain from data collection to secure delivery from the competition site.

[0067] In some exemplary embodiments, the smart contract module is used for: The contestants' scores are weighted according to the weight of the competition level and the regional difficulty coefficient to obtain the comprehensive score.

[0068] In this embodiment, the weighted calculation specifically refers to a mathematical calculation process. Its core is to scale numerical values ​​from different sources or with different levels of importance by multiplying them by a specific coefficient (weight), and then combining them to obtain a single value that better reflects the overall situation. Here, the weight refers to the weight corresponding to the competition level and the regional difficulty coefficient. Through weighting, the value of a result in a top-level international competition held in a high-difficulty plateau region (high regional coefficient) (high level weight) will be far higher than the equivalent result in an ordinary competition held in a plains region. This ensures that the calculated overall score fairly reflects the athlete's comprehensive competitive level under different conditions and in competitions of different levels.

[0069] The steps involved in implementing the core logic of competition rights management, namely the calculation of overall scores, through smart contracts may include: Step 1: Parameter Preparation: Once a transaction containing new tournament results is confirmed by consensus and triggers the smart contract, the contract code first reads three core inputs from the on-chain state database or the transaction input parameters: (The contestant's original score, if in seconds) (The weighting of this competition level is a predefined floating-point number, such as 1.5 for the Gold Label competition.) (The regional difficulty coefficient of this competition, a dynamic or predefined floating-point number).

[0070] Step 2: Single-round score weighting: The smart contract performs one multiplication operation: It's important to note here that in a marathon scenario, a smaller time (shorter time) generally indicates a higher skill level. Therefore, a more intuitive approach, aligning with the logic that higher scores are always better, is to first convert the raw time into a standardized score, or use a reciprocal format, before applying weighted averages. For simplicity, this can be understood as... This is a standardized indicator; a higher value indicates better performance. Calculation results. This represents the player's effective contribution value in this competition, after adjustments for difficulty and level.

[0071] Step 3: Accumulate Overall Score: The contract then accesses the contestant's on-chain account status and reads their historical overall score (a cumulative value, initially 0). This cumulative score is then used to calculate... Added to the overall historical score: .

[0072] Step 4: State Update: Update the calculated new state Write back to the contestant's on-chain account status to complete the dynamic update of the overall score. This new overall score will serve as the input for all subsequent smart contract logic that relies on this score (such as contestant eligibility verification and ranking).

[0073] For example, the following concrete example illustrates how a smart contract can perform on-chain calculation of the overall score: Suppose contestant A has the following on-chain record of their historical comprehensive score: In a new race, the athlete's original finishing time (athlete's time) was... This event is certified as an IAAF Gold Label event (event level), and its preset fixed weight value is... The competition is being held in a high-altitude city. The smart contract, based on the city's terrain, altitude, and weather data at the time of the competition, uses pre-stored machine learning models on the blockchain to calculate the regional difficulty coefficient of the event. .

[0074] The edge computing node will contain Event level identification Once the encrypted data package is uploaded to the blockchain network and confirmed through consensus, the on-chain smart contract for calculating scores is automatically triggered and executed. The contract's execution logic is as follows: Data parsing and parameter mapping: The contract code parses key data from on-chain transactions. Based on the competition level identifier, the contract queries the on-chain weight mapping table to obtain the corresponding... At the same time, confirm the use of .

[0075] Standardization and weighted calculation: The contract first processes the raw scores... Standardize it to convert it into a value P that is positively correlated with performance (e.g., using...). The formula is used, where K is a constant, so that the shorter the time, the larger the P value. Next, the contract performs the core weighted calculation to calculate the contribution value ΔScore of this competition to the overall score: That is, ΔScore = 1.5 × 1.3 × P.

[0076] Overall Score Update: The contract then accesses the on-chain state database to read contestant A's current Score_old. Then, it adds this contribution value to the historical scores to calculate the new overall score. : .

[0077] State Write: Finally, the contract updates the blockchain network's state database with Score_new as contestant A's latest overall score, and generates a corresponding state update transaction record. This will serve as the basis for determining the logic of smart contracts such as the subsequent dynamic adjustment of participation rights.

[0078] In some exemplary embodiments, the preset conditions include performance threshold conditions and economic promotion needs; The smart contract module is used to execute performance threshold conditions to determine whether the overall score has reached the preset threshold. The participation rights allocation engine is used to generate participation rights allocation schemes by combining economic promotion needs.

[0079] The performance threshold is a quantifiable standard pre-set by the competition organizing committee and encoded in a smart contract. Its core is a preset threshold (e.g., a combined score ≥ 600 points). This condition serves as a hard filter for eligibility verification; only when a participant's combined score reaches or exceeds this threshold will their application proceed to the more complex allocation process, ensuring the basic competitive level of the competition.

[0080] In some exemplary embodiments, the economic stimulus demand includes at least one of the following: Tourism consumption will be promoted by offering discounted tickets to coastal scenic spots in the event venue to athletes from inland areas. Brand promotion and incentives include providing free entry to contestants whose social media followers exceed a first threshold. Industry cooperation is promoted, and competition slots are reserved for senior executives of sports equipment companies.

[0081] Economic promotion needs: As mentioned earlier, this is a strategic objective proactively set by the host city. In this set of embodiments, it is concretized into actionable subcategories: tourism consumption promotion aims to directly boost the local tourism industry; brand promotion promotion aims to leverage the social influence of athletes to expand the visibility of the event and the city; and industry cooperation promotion aims to establish or deepen business ties with specific industries (such as sports equipment) to attract investment or consumption.

[0082] For example, when a contestant submits their application, a smart contract for qualification verification is triggered. This contract first enforces the performance threshold: it reads the contestant's latest overall score from the blockchain and compares it to a preset threshold stored on the blockchain for the corresponding competition. If the score is not met, the contract immediately returns a result indicating disqualification and records the reason. This process is fully automated and requires no human intervention.

[0083] For participants who pass today's selection process, their information (ID, overall score, place of origin, etc.) is passed to the off-chain participation allocation engine. The engine reads the specific economic promotion requirements configured for this event (e.g., allocating 100 slots with ticket discounts to inland participants, and inviting 5 KOLs with over 500,000 followers). Based on these requirements, the engine runs a matching algorithm among the qualified participants. For example, it first filters out all participants from inland areas, selects the top 100 based on their overall score, and marks them as eligible for tourism consumption promotion; then it filters out participants with over 500,000 followers, selects the top 5 based on their overall score, and marks them as eligible for brand promotion promotion. A structured allocation list is generated.

[0084] The allocation engine submits the final allocation list to the blockchain, triggering an empowerment smart contract. After verifying the list signature, the contract automatically mints or activates the corresponding type of digital certificate (e.g., a special NFT entry certificate containing ticket discount benefits) in each participant's on-chain account based on their eligibility type in the list.

[0085] In some exemplary embodiments, the smart contract module is also used to perform at least one of the following functions: Anomaly detection is performed based on the segmented time data of the contestants uploaded by the edge computing nodes to identify cheating behavior; The system accesses real-time meteorological data and adjusts the contestants' scores based on a preset environmental compensation algorithm.

[0086] Among them, the athlete's segmented time data refers to the cumulative time sequence recorded at different timing points (such as every 5 kilometers) along the marathon course. This data sequence implicitly contains the athlete's speed variation curve and is a key basis for analyzing the rationality of their competition behavior.

[0087] Anomaly detection: In this embodiment, the smart contract analyzes the segmented time sequence and uses pre-set rules or models to identify patterns that do not conform to the characteristics of marathon running. For example, the time between adjacent segments is extremely short (possibly due to travel by vehicle), or the overall speed curve exhibits impossible biomechanical characteristics.

[0088] Environmental compensation algorithm: A predefined mathematical adjustment rule used to fairly correct competitors' original scores based on actual environmental conditions. For example, under high-temperature conditions, the algorithm may linearly or non-linearly extend the effective completion time threshold based on the temperature value, ensuring that competitors who finish in adverse weather conditions receive a relatively fair evaluation.

[0089] For anomaly detection, the anti-cheating smart contract is configured to execute periodically (e.g., every minute) or event-driven. It retrieves all segment time data for a specified competitor from the blockchain and calculates the pace of adjacent segments. If any segment's pace exceeds human limits (e.g., below 2 minutes per kilometer), or if pace changes violate physiological laws, the contract automatically marks the competitor's record as an anomaly and generates an on-chain event pending review, notifying the race judges. All calculations and results are stored on the blockchain.

[0090] For example, when analyzing race data from runner C, the on-chain anti-cheating smart contract discovered extreme anomalies in his segment times: his 0-10km segment time was 40 minutes (average pace of approximately 4 minutes 0 seconds / km), while the subsequent 10-15km segment time was only 5 minutes (average pace as high as 1 minute 0 seconds / km). This pace far exceeds the current physiological limits of human marathon running and shows a huge difference from the pace of the preceding and following segments, which is inconsistent with the laws of long-distance running. Based on this, the smart contract immediately determined, according to pre-set rules, that the segment data was highly suspected of cheating (such as possible use of transportation during the race), automatically marked runner C's race record as "data abnormal, pending review," and simultaneously generated and uploaded a warning event to the blockchain. This event is pushed in real time to the dedicated management backend interface of the race referee team, prompting the referees to pay close attention and initiate a manual investigation. This mechanism achieves automated, real-time preliminary screening and evidence collection of cheating behavior.

[0091] For environmental compensation, the performance compensation smart contract connects to an authoritative meteorological data source (via an oracle). During the competition, the contract acquires real-time temperature and humidity data. If the data exceeds a preset compensation trigger threshold (e.g., temperature > 30℃), the contract dynamically adjusts the scores of subsequent finishers based on an algorithm (e.g., adjusted score = original score × (1 + 0.01 * (real-time temperature - baseline temperature))). The adjusted score is then used as the input for subsequent weighted calculations, ensuring the comparability of scores under different weather conditions.

[0092] For example, when analyzing race data from runner C, the on-chain anti-cheating smart contract discovered extreme anomalies in his segment times: his 0-10km segment time was 40 minutes (average pace of approximately 4 minutes 0 seconds / km), while the subsequent 10-15km segment time was only 5 minutes (average pace as high as 1 minute 0 seconds / km). This pace far exceeds the current physiological limits of human marathon running and shows a huge difference from the pace of the preceding and following segments, which is inconsistent with the laws of long-distance running. Based on this, the smart contract immediately determined, according to pre-set rules, that the segment data was highly suspected of cheating (such as possible use of transportation during the race), automatically marked runner C's race record as "data abnormal, pending review," and simultaneously generated and uploaded a warning event to the blockchain. This event is pushed in real time to the dedicated management backend interface of the race referee team, prompting the referees to pay close attention and initiate a manual investigation. This mechanism achieves automated, real-time preliminary screening and evidence collection of cheating behavior.

[0093] In some exemplary embodiments, the system also includes an economic promotion module, which is used to match and recommend distinctive tourism resources of the event venue through a smart contract module based on the contestants' place of origin information and historical participation records.

[0094] The economic promotion module refers to a software component, either independent or integrated into the participation rights allocation engine, which is specifically responsible for mining the economic value of event data and proactively generating suggestions to promote consumption or triggering corresponding actions.

[0095] For example, the economic promotion module is triggered after a contestant successfully registers or completes the race. It queries the contestant's place of origin and past race records on the blockchain via a smart contract. Internally, the module maintains a tourism resource knowledge graph, where nodes represent attractions and edges represent attributes (such as coastline, mountainous terrain, and historical culture). Based on the contestant's place of origin (e.g., Inner Mongolia), the module infers the types of resources that might interest them that differ significantly from their usual residence (e.g., coastline). Simultaneously, it analyzes their past race records to understand their frequently visited regions and avoid duplicate recommendations.

[0096] Based on the above analysis, the module sends personalized recommendations to participants' event apps or associated travel platforms by invoking smart contracts. For example, based on your participation record, we recommend local beach resort X, where you can enjoy a 20% discount with your race bib. The entire recommendation logic and the generation of discount vouchers can be completed through smart contracts and stored on the blockchain.

[0097] In some exemplary embodiments, the system further includes a security and auditing module for: Asymmetric encryption technology is used to authenticate the contestants' identities; All system operation records are written to the blockchain network for evidence storage.

[0098] The authentication process involves several steps: When a participant logs in or performs a critical operation, they are required to sign a random challenge using their private key. The security and auditing module (or authentication submodule) receives the signature and verifies it using the participant's public key (registered on the blockchain). If verification is successful, access is granted. This ensures that the operator is also the account owner, preventing account theft.

[0099] Operation Evidence Storage: Any critical operation of the system, such as grade entry, qualification verification, or rule modification, generates a record containing the operation content, operator identity, and timestamp after it occurs. This module ensures that each such record is sent to the blockchain network as a transaction. After consensus is reached, these records are permanently written to the blockchain, forming an immutable and chronologically clear audit log.

[0100] In some exemplary embodiments, the competition level includes IAAF Gold Label events, domestic Class A events, domestic Class B events, domestic Class C events, and domestic Class D events, each corresponding to a predetermined weight value; the regional difficulty coefficient is dynamically determined based on the terrain, altitude, and climate data of the event location.

[0101] The event level and weight value can be determined based on a global mapping table maintained by the system on-chain or in an authoritative configuration file. For example: {“IAAF Gold Label Events”: 1.5, “Domestic Category A Events”: 1.2, “Domestic Category B Events”: 1.0, “Domestic Category C Events”: 0.8, “Domestic Category D Events”: 0.6}. When it is necessary to determine the weight of an event, the specific value is obtained by querying this table.

[0102] The base value of the regional difficulty coefficient can be pre-calculated and stored based on historical data (topography, average altitude, climate zone) of the host city. Before or during the competition, it can be fine-tuned using a lightweight model by combining real-time or forecast weather data (such as competition day temperature, wind speed, and precipitation probability). The coefficient used for the final calculation is the value corrected for real-time data.

[0103] The participation rights management system provided in this application constructs a blockchain network consisting of provincial nodes and core nodes, and utilizes the PBFT consensus algorithm to ensure reliable interaction between nodes. This provides an immutable and traceable foundation for evidence storage of participation rights data at the system architecture level. Simultaneously, by deploying edge computing nodes on-site, real-time collection and localized processing of core data such as contestant scores, competition levels, and regional difficulty coefficients are achieved, effectively reducing data upload latency and network dependence, and improving data processing timeliness. Furthermore, the smart contract module deployed in the blockchain network can automatically determine the overall score and dynamically adjust participation rights based on the collected multi-dimensional data. The participation rights allocation engine, by integrating multi-source information such as score data, city needs, and contestant influence, automatically generates a more adaptable allocation scheme. This significantly improves the accuracy, fairness, and execution efficiency of participation rights management while ensuring the automation and transparency of the allocation process.

[0104] Figure 2 This is a flowchart illustrating an exemplary embodiment of a competition rights management method, which is applied to a competition rights management system. Figure 2 As shown, the method includes: Step 210: Collect data on contestant scores, competition level, and regional difficulty coefficient in real time through edge computing nodes.

[0105] Step 220: The smart contract module determines the overall score based on the contestant's performance, competition level, and regional difficulty coefficient data, and dynamically adjusts the right to participate based on the overall score and preset conditions.

[0106] Step 230: The participation rights allocation engine generates a participation rights allocation plan based on the overall scores, the host city's needs, and the participants' influence data.

[0107] The participation rights management method provided in this application constructs a blockchain network consisting of provincial nodes and core nodes, and utilizes the PBFT consensus algorithm to ensure reliable interaction between nodes. This provides an immutable and traceable basic evidence storage capability for participation rights data at the system architecture level. Simultaneously, by deploying edge computing nodes on-site, real-time collection and localized processing of core data such as contestant scores, competition level, and regional difficulty coefficients are achieved, effectively reducing data upload latency and network dependence, and improving data processing timeliness. Furthermore, the smart contract module deployed in the blockchain network can automatically determine the overall score and dynamically adjust participation rights based on the collected multi-dimensional data. The participation rights allocation engine automatically generates a more adaptable allocation scheme by integrating multi-source information such as score data, city needs, and contestant influence. This significantly improves the accuracy, fairness, and execution efficiency of participation rights management while ensuring the automation and transparency of the allocation process.

[0108] The participation rights management method can achieve Figure 1 For details regarding the method in the system implementation, please refer to... Figure 1 The participation rights management system shown in the embodiment will not be described in detail again.

[0109] Figure 3 This is a schematic diagram of the structure of a competition rights management device 300 provided for an exemplary embodiment of this application. Figure 3 As shown, the device 300 includes: a data acquisition module 310, a participation rights adjustment module 320, and a participation rights allocation module 330, wherein: Data acquisition module 310 is used to collect data on contestant scores, competition level, and regional difficulty coefficient in real time through edge computing nodes; The participation rights adjustment module 320 is used to determine the overall score based on the contestant's performance, competition level, and regional difficulty coefficient data through the smart contract module, and to dynamically adjust the participation rights based on the overall score and preset conditions. The participation rights allocation module 330 is used to generate a participation rights allocation scheme based on the overall score, the host city's needs, and the contestant's influence data through the participation rights allocation engine.

[0110] The participation rights management device provided in this application constructs a blockchain network consisting of provincial nodes and core nodes, and utilizes the PBFT consensus algorithm to ensure reliable interaction between nodes. This provides an immutable and traceable foundation for evidence storage of participation rights data at the system architecture level. Simultaneously, by deploying edge computing nodes on-site, real-time collection and localized processing of core data such as contestant scores, competition levels, and regional difficulty coefficients are achieved, effectively reducing data upload latency and network dependence, and improving data processing timeliness. Furthermore, the smart contract module deployed in the blockchain network can automatically determine the overall score and dynamically adjust participation rights based on the collected multi-dimensional data. The participation rights allocation engine automatically generates a more adaptable allocation scheme by integrating multi-source information such as score data, city needs, and contestant influence. This significantly improves the accuracy, fairness, and execution efficiency of participation rights management while ensuring the automation and transparency of the allocation process.

[0111] The participation rights management method can achieve Figure 1 and Figure 2 The method described in the embodiments can be found in the following examples. Figure 1 and Figure 2 The participation rights management system and method shown in the embodiments will not be described in detail again.

[0112] Figure 4 This is a schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this application. For example... Figure 4As shown, the device includes a memory 41 and a processor 42.

[0113] Memory 41 is used to store computer programs and can be configured to store various other data to support operation on the computing device. Examples of this data include instructions for any application or method used to operate on the computing device, contact data, phone book data, messages, images, videos, etc.

[0114] The processor 42, coupled to the memory 41, is used to execute the computer program in the memory 41 for: collecting contestant scores, competition level, and regional difficulty coefficient data in real time through edge computing nodes; determining the overall score based on the contestant scores, competition level, and regional difficulty coefficient data through the smart contract module, and dynamically adjusting the right to participate based on the overall score and preset conditions; and generating a right to participate allocation scheme based on the overall score, the host city's requirements, and contestant influence data through the right to participate allocation engine.

[0115] The electronic device provided in this application embodiment constructs a blockchain network consisting of provincial nodes and core nodes, and utilizes the PBFT consensus algorithm to ensure reliable interaction between nodes. This provides an immutable and traceable foundation for evidence storage of participation rights data at the system architecture level. Simultaneously, by deploying edge computing nodes on-site, it achieves real-time collection and localized processing of core data such as contestant scores, competition level, and regional difficulty coefficients, effectively reducing data upload latency and network dependence, and improving data processing timeliness. Furthermore, the smart contract module deployed in the blockchain network can automatically determine the overall score and dynamically adjust participation rights based on the collected multi-dimensional data. The participation rights allocation engine, by integrating multi-source information such as score data, city needs, and contestant influence, automatically generates a more adaptable allocation scheme. This significantly improves the accuracy, fairness, and execution efficiency of participation rights management while ensuring the automation and transparency of the allocation process.

[0116] Furthermore, such as Figure 4 As shown, the electronic device also includes other components such as a communication component 43, a display 44, a power supply component 45, and an audio component 46. Figure 4 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 4 The components shown. Additionally, depending on the implementation of the traffic playback device, Figure 4 The components within the dashed box are optional, not mandatory. For example, when an electronic device is implemented as a terminal device such as a smartphone, tablet, or desktop computer, it may include... Figure 4 The components within the dashed box; when the electronic device is implemented as a server-side device such as a conventional server, cloud server, data center, or server array, it may be excluded. Figure 4The component within the dashed box.

[0117] The above Figure 4 The communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as WiFi, 2G, or 3G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component may further include a Near Field Communication (NFC) module, Radio Frequency Identification (RFID) technology, Infrared Data Association (IrDA) technology, Ultra Wideband (UWB) technology, Bluetooth (BT) technology, etc.

[0118] The above Figure 4 The memory in the memory can be implemented by any class of volatile or non-volatile storage devices or combinations thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0119] The above Figure 4 The display includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of the touch or swipe action, but also the duration and pressure associated with the touch or swipe operation.

[0120] The above Figure 4 The power supply component provides power to the various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which it resides.

[0121] The above Figure 4 The audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0122] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments.

[0123] Accordingly, this application also provides a computer program product, which stores instructions that, when executed by a computer, cause the computer to perform the steps in the competition rights management method embodiment provided in this application.

[0124] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0125] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0126] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0127] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0128] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0129] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0130] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other classes of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0131] It should also be noted that 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 limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0132] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A competition rights management system, characterized in that, include: The blockchain network consists of provincial nodes deployed in various provincial-level administrative regions and core nodes deployed in the Chinese Athletics Association. The provincial nodes adopt the Hyperledger Fabric framework, and the nodes interact with each other through the Practical Byzantine Fault-Tolerant PBFT consensus algorithm. Edge computing nodes, deployed at the event site, communicate with the blockchain network to collect data on contestant scores, event level, and regional difficulty coefficients in real time. The smart contract module, deployed in the blockchain network, is used to determine the overall score based on the contestant's performance, the level of the competition, and the regional difficulty coefficient data, and to dynamically adjust the right to participate based on the overall score and preset conditions. The participation rights allocation engine, coupled to the smart contract module, is used to generate a participation rights allocation scheme based on the overall scores, the host city's requirements, and the contestants' influence data.

2. The system as described in claim 1, characterized in that, The edge computing nodes are deployed at the marathon event site and communicate with provincial nodes in the blockchain network via a 5G network. They are used to encrypt and compress the collected data on athlete scores, event level, and regional difficulty coefficients, and to perform preliminary verification of the athlete scores.

3. The system as described in claim 1, characterized in that, The smart contract module is used for: The contestants' scores are weighted based on the weights corresponding to the competition level and the regional difficulty coefficient to obtain the overall score.

4. The system as described in claim 1, characterized in that, The preset conditions include performance threshold conditions and economic promotion needs; The smart contract module is used to execute the performance threshold condition to determine whether the overall score has reached the preset threshold. The participation rights allocation engine is used to generate the participation rights allocation scheme in conjunction with the economic promotion needs.

5. The system as described in claim 4, characterized in that, The economic stimulus demand includes at least one of the following: Tourism consumption will be promoted by offering discounted tickets to coastal scenic spots in the event venue to athletes from inland areas. Brand promotion and incentives include providing free entry to contestants whose social media followers exceed a first threshold. Industry cooperation is promoted, and competition slots are reserved for senior executives of sports equipment companies.

6. The system as described in claim 1, characterized in that, The smart contract module is also used to perform at least one of the following functions: Based on the contestant segment time data uploaded by the edge computing node, anomaly detection is performed to identify cheating behavior; The system accesses real-time meteorological data and adjusts the contestants' scores based on a preset environmental compensation algorithm.

7. The system as described in claim 1, characterized in that, The system also includes an economic promotion module, which is used to match and recommend distinctive tourism resources of the event venue based on the contestants' place of origin and historical participation records through the smart contract module.

8. The system as described in claim 1, characterized in that, The system also includes a security and auditing module, used for: Asymmetric encryption technology is used to authenticate the contestants' identities; All system operation records are written to the blockchain network for storage.

9. The system as described in claim 1, characterized in that, The competition levels include IAAF Gold Label events, domestic Class A events, domestic Class B events, domestic Class C events, and domestic Class D events, each with a predetermined weight value; the regional difficulty coefficient is dynamically determined based on the terrain, altitude, and climate data of the event location.

10. A method for managing participation rights, characterized in that, The method is applied to the participation rights management system according to any one of claims 1 to 9, comprising: Real-time data collection of contestant scores, competition level, and regional difficulty coefficients is achieved through edge computing nodes; The smart contract module determines the overall score based on the contestant's performance, the level of the competition, and the regional difficulty coefficient, and dynamically adjusts the right to participate based on the overall score and preset conditions. The participation rights allocation engine generates a participation rights allocation scheme based on the overall scores, the host city's needs, and the participants' influence data.

Images