Blockchain-based sports event process information management method

Abstract

The application discloses a sports event process information management method based on a block chain and belongs to the technical field of block chain sports event process management. The method comprises the following steps: acquiring global configuration parameters and a list of participating teams and generating an initial event process chain, which comprises a plurality of competition round nodes arranged according to time; generating an initial schedule time mapping table between the competition rounds and the teams; generating an event block sequence according to the process chain and the mapping table, wherein each block corresponds to a round node; collecting real-time competition schedule execution data of each round and comparing the data with standard data in the mapping table field by field, and generating a to-be-verified block according to the comparison result; broadcasting the to-be-verified block to a plurality of verification nodes for double verification according to the global configuration parameters to obtain verification pass information; and storing the to-be-verified block in an event main chain according to the verification pass information and updating the process state. The application realizes transparent and tamper-proof management of the event process.

Description

Technical Field

[0001] This invention relates to the field of blockchain sports event process management technology, specifically a blockchain-based information management method for sports event processes. Background Technology

[0002] Sports event process management involves aspects such as match round scheduling, team pairings, match time control, and schedule execution records. Current management methods typically store schedules and match data on a centralized server or event management system. Event organizers or third-party personnel input information such as match start and end times and participating team lists, and perform simple format checks within the system. Deviations between the executed event data and the preset schedule largely rely on manual verification, with the recorded results based on individual data in the central database. Centralized storage makes it difficult to prove data integrity in case of disputes, and historical records can be modified by nodes with administrative privileges. Match execution data includes time-related fields and team identification fields. Existing verification methods typically only check the input format or field integrity, failing to separately verify whether timestamps exceed tolerance limits or whether participating team identifiers are on whitelists.

[0003] Before the execution data of the competition schedule is generated into a block, there is a lack of a mechanism for comparing differences between different fields field by field and for verification by multiple verification nodes. Abnormal schedule data may be directly written into the process record, affecting the credibility of the competition process information. Deviations between the execution data of the competition schedule and the preset schedule data cannot form a credible record on the chain. Anomalies in time-related fields and team identification fields lack targeted identification, making it difficult for the information management of the competition process to simultaneously achieve process traceability and anomaly interception. Summary of the Invention

[0004] To address the issues of easily tampered schedule data, lack of field-level records for deviations between executed schedule data and preset schedules, and lack of targeted double verification for time-related and team identification fields in existing sports event process information management, this paper proposes a blockchain-based method for sports event process information management. This method generates an initial event process chain and an initial schedule time mapping table, and generates an event block sequence. It collects executed schedule data and compares it field-by-field with standard schedule data to generate blocks to be verified. Multiple verification nodes perform double verification on the timestamp and team identification fields according to global configuration parameters before associating and storing the data on the main event chain, thus achieving reliable evidence storage and anomaly interception of event process information.

[0005] To achieve the above objectives, the present invention provides the following technical solution: The present invention provides a blockchain-based information management method for sports event processes, comprising:

[0006] Obtain the global configuration parameters and the list of participating teams for the current event. Based on the global configuration parameters and the list of participating teams, generate an initial event process chain, which contains multiple rounds of competition nodes arranged in chronological order.

[0007] Based on the list of participating teams and the multiple competition round nodes, an initial schedule time mapping table between the competition rounds and the participating teams is generated.

[0008] Based on the initial event flow chain and the initial event schedule time mapping table, an event block sequence is generated, and each event block in the event block sequence corresponds to a competition round node;

[0009] Real-time collection of schedule execution data for each round of the competition; comparison of the schedule execution data with the corresponding standard schedule data in the initial schedule time mapping table field by field; and generation of a block to be verified based on the comparison results.

[0010] The block to be verified is broadcast to multiple verification nodes in the blockchain network. The multiple verification nodes perform double verification on the block to be verified according to the global configuration parameters to obtain verification pass information.

[0011] Based on the verification pass information, the block to be verified is associated with the confirmation block and stored on the main chain of the blockchain network, and the process status of the initial event process chain is updated.

[0012] This invention divides the competition process into multiple competition round nodes and generates corresponding competition blocks, enabling the initial process, schedule mapping, and actual execution data of the competition to be recorded and verified in the blockchain network. After comparing the schedule execution data with standard data field by field, a block to be verified is generated. Multiple verification nodes perform double verification based on global configuration parameters, which can reduce the risk of the schedule execution record being tampered with or misrecorded, and improve the traceability and credibility of the competition process data.

[0013] Preferably, based on the list of participating teams and multiple round nodes, an initial schedule time mapping table is generated between the rounds and the participating teams. This includes: generating a matchup graph for each participating team based on their historical head-to-head records; extracting a preset time period corresponding to each round node from the initial event flow chain based on the order of the multiple round nodes in the chain; and assigning team pairings to each round node based on the matchup graph and the preset time periods, thus generating the initial schedule time mapping table. Generating the matchup graph from historical head-to-head records and assigning pairings accordingly ensures that the initial schedule considers the matchup relationships between teams during the generation phase, which helps improve the rationality of the schedule arrangement.

[0014] Preferably, a tournament block sequence is generated based on the initial tournament flow chain and the initial tournament schedule time mapping table. This includes: extracting the team matchups and match time periods corresponding to each tournament round node from the initial tournament schedule time mapping table according to the order of the multiple tournament round nodes in the initial tournament flow chain; generating a first block hash value based on the team matchups and a second block hash value based on the match time periods; concatenating the first and second block hash values ​​to generate the tournament block corresponding to each tournament round node; and arranging all tournament blocks in chronological order to obtain the tournament block sequence. Since the hash value of each tournament block is associated with the team matchups and match time periods, the block sequence can stably correspond to the tournament schedule content, and any changes to the tournament schedule will be reflected in the block hashes, thus facilitating subsequent verification and traceability.

[0015] Preferably, the execution data of each competition round node is collected in real time. This execution data is then compared field-by-field with the corresponding standard competition data in the initial competition time mapping table. Based on the comparison results, a block to be verified is generated. This process includes: extracting the standard competition data corresponding to the current competition round node from the initial competition time mapping table; the standard competition data includes the standard competition time interval and the standard list of participating teams; collecting the actual start time, actual end time, and actual list of participating teams for the current competition round node in real time as the execution data; performing an interval inclusion comparison between the actual start time and actual end time and the standard competition time interval; and performing a member consistency comparison between the actual list of participating teams and the standard list of participating teams. Based on the results of the interval inclusion comparison and the member consistency comparison, a block to be verified is generated. Therefore, the actual execution data can only form a block to be verified if the comparison result with the standard competition data meets the requirements, preventing matches that do not follow the predetermined schedule from being directly confirmed and improving the standardization of competition execution.

[0016] Preferably, the block to be verified is broadcast to multiple verification nodes in the blockchain network. These nodes perform dual verification of the block according to global configuration parameters to obtain verification pass information. This includes: selecting a first subset and a second subset of verification nodes from the multiple verification nodes, with the number of nodes in both subsets being the same; sending the timestamp field from the block to be verified to the first subset of verification nodes, which performs a first verification on the timestamp field according to the time tolerance threshold in the global configuration parameters; sending the team identifier field from the block to be verified to the second subset of verification nodes, which performs a second verification on the team identifier field according to the team identifier whitelist in the global configuration parameters; receiving the first verification result returned by the first subset of verification nodes and the second verification result returned by the second subset of verification nodes. When both the first and second verification results are verified as pass, verification pass information is obtained. This dual verification using the timestamp field and the team identifier field verifies both the reasonableness of the competition time and the legitimacy of the participating teams, improving verification efficiency and reducing the risk of misjudgment caused by verification by a single node.

[0017] Preferably, the timestamp field of the block to be verified is sent to the first subset of verification nodes. The first subset of verification nodes performs a first verification on the timestamp field according to the time tolerance threshold in the global configuration parameters. This includes: obtaining the timestamp field in the block to be verified, whereby the timestamp field includes a start timestamp and an end timestamp; each verification node in the first subset of verification nodes calculates a first time difference between the start timestamp and the current system time, and a second time difference between the end timestamp and the start timestamp; and determines whether the first time difference is less than the time tolerance threshold and whether the second time difference is greater than the preset minimum match duration. When both conditions are met, each verification node outputs a first verification result indicating that the verification has passed.

[0018] Preferably, the team identifier field from the block to be verified is sent to the second set of verification nodes. The second set of verification nodes then performs a second verification on the team identifier field based on the team identifier whitelist in the global configuration parameters. This includes: obtaining the team identifier field from the block to be verified, whereby the team identifier field contains the first participating team identifier and the second participating team identifier; each verification node in the second set of verification nodes searching for the first participating team identifier and the second participating team identifier in the team identifier whitelist; and when both the first participating team identifier and the second participating team identifier exist in the team identifier whitelist, each verification node outputs a second verification result indicating that the verification has passed.

[0019] Preferably, based on the verification pass information, the block to be verified is associated with and stored as a confirmation block on the main chain of the blockchain network, and the process status of the initial event flow chain is updated. This includes: obtaining the block hash value of the last block on the main chain of the blockchain network, using the block hash value of the last block as the forward block hash value of the confirmation block; packaging the forward block hash value of the confirmation block, the main data of the confirmation block, and the timestamp of the confirmation block into a new block, and attaching the new blockchain to the end of the last block; updating the node status of the competition round node corresponding to the confirmation block in the initial event flow chain from unexecuted to executed. Thus, the confirmation block is associated with the existing main chain through forward hashing, ensuring the continuity and immutability of the main chain of the event, while the process status is updated synchronously, making the event progress clearly traceable on the chain.

[0020] Preferably, based on global configuration parameters and the list of participating teams, an initial tournament process chain is generated, including: generating a preset number of tournament round nodes based on the total number of tournament rounds in the global configuration parameters and the total number of teams in the list of participating teams; sequentially connecting the preset number of tournament round nodes in chronological order according to the total number of tournament rounds, embedding a node hash value in each tournament round node, the node hash value being generated based on the node hash value of the previous tournament round node and the round number of the current tournament round node; and using the pre-set number of connected tournament round nodes as the initial tournament process chain. The node hashes in the initial tournament process chain are sequentially associated to form a tamper-proof process structure, ensuring that the order and number of the initial tournament rounds are difficult to modify individually after generation.

[0021] Preferably, the interval inclusion comparison includes: when the actual start time of the match is not earlier than the start time of the standard match time interval and the actual end time of the match is not later than the end time of the standard match time interval, the interval inclusion comparison is determined to be successful.

[0022] The technical effects and advantages provided by the present invention in the above technical solution are as follows:

[0023] An initial tournament process chain and an initial tournament schedule time mapping table are generated by using global configuration parameters and a list of participating teams. A tournament block sequence is then generated according to the tournament round nodes. After obtaining the actual start time, end time, and participating team list, the aforementioned tournament execution data is compared field-by-field with the standard tournament time intervals and standard participating team list in the initial tournament schedule time mapping table. Based on the interval inclusion and member consistency results, a block to be verified is generated. This processing method incorporates tournament execution deviations into the block to be verified as field-level differences, rather than simply storing the final tournament results. This ensures that deviations between the tournament execution data and the preset tournament schedule data can be recorded and traced by the blockchain. Compared to a single record in a centralized database, on-chain field-level comparison results are less susceptible to local modification, reducing the risk of tournament process information being tampered with.

[0024] The timestamp and team identifier fields in the block to be verified are respectively handled by a first subset of verification nodes and a second subset of verification nodes. The first subset of verification nodes compares the start and end timestamps based on the time tolerance threshold in the global configuration parameters. The second subset of verification nodes searches for members of the first and second participating teams based on the team identifier whitelist in the global configuration parameters. The two subsets of verification nodes use different verification rules for time-related fields and team-related fields, and generate verification pass information when both verification results are successful. This method differs from single-format verification or single-node verification, enabling parallel verification of abnormal features of different field types, reducing the possibility of abnormal time data and abnormal team identifiers being written to the main chain of the event, and enhancing the credibility of the event process information. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0026] Figure 1 This is a flowchart of a blockchain-based method for information management of sports event processes.

[0027] Figure 2 This is a flowchart illustrating the method for generating the initial event process chain and event schedule time mapping table;

[0028] Figure 3 This is a flowchart of the main chain block generation and event status update process for the competition;

[0029] Figure 4 This is a diagram comparing the actual match time at each round's node with the standard match time interval. Detailed Implementation

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

[0031] See Figure 1This invention provides a blockchain-based method for information management of sports event processes, comprising: obtaining global configuration parameters and a list of participating teams for the current event; generating an initial event process chain based on the global configuration parameters and the list of participating teams, the initial event process chain containing multiple round nodes arranged in chronological order; generating an initial schedule time mapping table between rounds and participating teams based on the list of participating teams and the multiple round nodes; generating an event block sequence based on the initial event process chain and the initial schedule time mapping table, each event block in the event block sequence corresponding to a round node; collecting the schedule execution data of each round node in real time, comparing the schedule execution data with the corresponding standard schedule data in the initial schedule time mapping table field by field, and generating a block to be verified based on the comparison results; broadcasting the block to be verified to multiple verification nodes in the blockchain network, whereby the multiple verification nodes perform double verification on the block to be verified according to the global configuration parameters to obtain verification pass information; and storing the block to be verified as a confirmation block on the event main chain of the blockchain network and updating the process status of the initial event process chain based on the verification pass information.

[0032] In specific implementation, please refer to Figure 2 This process retrieves the global configuration parameters and the list of participating teams for the current event. The global configuration parameters include the total number of rounds, and the list of participating teams includes the total number of teams. Based on the total number of rounds and the total number of teams in the list, a preset number of round nodes are generated. The preset number of round nodes is equal to the total number of rounds, and each round node corresponds to one round.

[0033] The nodes for each round are sequentially linked together according to the total number of rounds. The linking operation is as follows: the successor pointer of the first round node is set to the second round node, the successor pointer of the second round node is set to the third round node, and so on, until the Mth round node, where M represents the total number of rounds. The successor pointer of the Mth round node is set to null.

[0034] Embed a node hash value in each round node. The node hash value is generated based on the node hash value of the previous round node and the round number of the current round node. The formula for generating the node hash value is:

[0035]

[0036] in, Indicates the forward sequence number of the competition round node. Starting from 1 and increasing; Indicates the first The node hash value embedded in each round of the competition; Indicates the first The node hash value embedded in each round of the competition; Indicates the first The round number of each round node in the competition; Indicates will and The corresponding byte sequences are concatenated in chronological order; This indicates the preset cryptographic hash function, using the SHA-256 algorithm. When hour, Use the preset initial node hash value , It is a fixed-length random byte string, set by the event organizer during the event initialization phase.

[0037] The pre-defined number of competition round nodes, linked together, serve as the initial competition process chain.

[0038] In practice, a rivalry graph is generated for each participating team based on their historical match records. These historical match records are stored in the tournament history database. For each participating team in the list, all their historical match records are retrieved from the database, and the identifiers of the opposing teams that have previously played against them are extracted. The participating team identifiers and their opponents' identifiers are used as vertices in the rivalry graph, and the lines connecting these identifiers are used as edges. Each edge in the rivalry graph represents one or more matches between two participating teams.

[0039] Based on the order of multiple competition round nodes in the initial competition flow chain, the preset time period corresponding to each competition round node is extracted from the initial competition flow chain. Each competition round node in the initial competition flow chain has a pre-set node time period attribute. According to the order of the competition round nodes, the node time period attribute of each competition round node is read, and the read node time period attribute is used as the preset time period for the corresponding competition round node.

[0040] Based on the adversarial graph and preset time periods, team pairings are assigned to each round node, generating an initial match schedule time mapping table. During the assignment process, for each round node, two different teams are selected from the list of participating teams to form a pairing. The two teams in each pairing have distinct identifiers, and an edge exists between them in the adversarial graph. The match time period corresponding to each pairing is the preset time period for that round node. The round number, team pairing, and preset time period for each round node are then written into the initial match schedule time mapping table.

[0041] In some embodiments, when the preset time periods of multiple competition round nodes overlap, the same participating team will not be assigned to the competition round node with the overlapping preset time periods.

[0042] Generate the initial match schedule time mapping table.

[0043] In practice, following the sequential order of multiple competition round nodes within the initial event flow chain, the corresponding team matchups and match time periods for each competition round node are extracted from the initial event schedule time mapping table. The multiple competition round nodes in the initial event flow chain have a specific order, determined by the chain's sequential arrangement. The round number of each competition round node is read according to this order, and the round number is then used to query the initial event schedule time mapping table to obtain the corresponding team matchups and match time periods. Each row in the initial event schedule time mapping table contains a round number field, a team matchup field, and a match time period field. The team matchup field records the identifiers of the two participating teams, and the match time period field records the start and end times of the match.

[0044] The first block hash value is generated based on the team matchups. The process is as follows: The first and second team identifiers from each matchup are obtained. These identifiers are then arranged lexicographically to obtain sorted team identifiers. The sorted team identifiers, a preset separator, and the second sorted team identifiers are concatenated in sequence to form the team matchup string. This string is then UTF-8 encoded to obtain the team matchup byte sequence. Finally, a preset cryptographic hash algorithm (SHA-256) is applied to this byte sequence to obtain the first block hash value.

[0045] The second block hash value is generated based on the match time period. The process is as follows: The start and end times of the match are obtained from the match time period. The start time is converted into a start time string according to a preset time format, and the end time is converted into an end time string according to a preset time format. The start time string, a preset separator, and the end time string are concatenated in sequence to form the match time period string. The match time period string is then encoded using UTF-8 to obtain a byte sequence of the match time period. The same preset cryptographic hash algorithm is applied to the byte sequence of the match time period to obtain the second block hash value. The preset time format uses ISO8601.

[0046] The hash values ​​of the first and second blocks are concatenated to generate the event block corresponding to each round of the competition. The concatenation method is as follows: the byte sequence of the first block hash value is placed first, and the byte sequence of the second block hash value is placed last to form the event block hash value. The event block hash value serves as the block identifier for the event block. In some embodiments, the event block hash value also serves as part of the main data of the event block.

[0047] The formula for generating the hash value of the event block is:

[0048]

[0049] in, This indicates the sorting sequence number determined according to the order of nodes in the initial event flow chain across multiple competition rounds. The total number of rounds increases from 1 to the number of nodes in the competition. Indicates the first The hash value of the event block corresponding to each competition round node; Indicates the first The hash value of the first block corresponding to each node in each round of the competition; Indicates the first The hash value of the second block corresponding to each node in each round of the competition; Indicates will byte sequence and byte sequence according to in front, Then they are assembled in the following order.

[0050] Arrange all event blocks in chronological order to obtain the event block sequence. Place each event block into the event block sequence according to the order of its corresponding round node, so that the [number]th event block in the event block sequence... The [number] event block corresponds to the [number]th event in the initial event process chain. Each round of the competition is a node.

[0051] In practice, the standard schedule data corresponding to the current round node is extracted from the initial schedule time mapping table. The current round node is the round node being executed in the initial event flow chain. The process of extracting the standard schedule data corresponding to the current round node is as follows: obtain the round number of the current round node; use the round number of the current round node as a query condition to search for records matching the round number of the current round node in the initial schedule time mapping table; and read the standard match time interval field and the standard participating team list field from the matching records. The standard schedule data includes the standard match time interval and the standard participating team list. The standard match time interval consists of the standard start time and the standard end time, and the standard participating team list includes the first standard participating team identifier and the second standard participating team identifier.

[0052] The actual start time, end time, and list of participating teams for each round of the competition are collected in real time and used as the schedule execution data. This real-time data collection is performed by the event data acquisition terminal located at the competition venue. The terminal records the actual start time when the referee signals the start of the match and the actual end time when the referee signals the end of the match. The list of participating teams is generated by the event data acquisition terminal from the match check-in system, and includes both the first and second participating team identifiers.

[0053] The actual start and end times of the match are compared with the standard match time interval. The comparison process is as follows: the actual start time is compared with the standard start time of the standard match time interval, and the actual end time is compared with the standard end time of the standard match time interval. If the actual start time is not earlier than the standard start time of the standard match time interval, and the actual end time is not later than the standard end time of the standard match time interval, the interval comparison is considered successful. If the actual start time is earlier than the standard start time of the standard match time interval, or the actual end time is later than the standard end time of the standard match time interval, the interval comparison is considered unsuccessful.

[0054] The actual participating team list is compared with the standard participating team list for consistency. The consistency comparison process is as follows: The first actual participating team identifier is compared with the first standard participating team identifier; the second actual participating team identifier is compared with the second standard participating team identifier; the first actual participating team identifier is compared with the second standard participating team identifier; and the second actual participating team identifier is compared with the first standard participating team identifier. If both the first and second actual participating team identifiers are the same, or if both are the same, the consistency comparison is considered successful. If both the first and second actual participating team identifiers are different from the first standard participating team identifier, the consistency comparison is considered unsuccessful. If both the second and third actual participating team identifiers are different from the first standard participating team identifier, the consistency comparison is considered unsuccessful.

[0055] Based on the results of the interval inclusion comparison and the member consistency comparison, a block to be verified is generated. A verification pass result is generated when both the interval inclusion comparison and the member consistency comparison pass. A verification fail result is generated when either the interval inclusion comparison or the member consistency comparison fails. The block to be verified contains the round number of the current competition round node, the actual start time of the competition, the actual end time of the competition, the list of actual participating teams, and the comparison result field. The comparison result field records whether the comparison passed or failed. The main data of the block to be verified consists of the round number of the current competition round node, the actual start time of the competition, the actual end time of the competition, the list of actual participating teams, and the comparison result field.

[0056] In some embodiments, when the comparison result field is a comparison failure result, an anomaly flag field is added to the block to be verified. The anomaly flag field records the type of comparison failure or member consistency comparison failure.

[0057] See Figure 4 In the graph, the horizontal axis represents the sequence number of multiple competition round nodes in the initial competition process chain, dimensionless, ranging from 0 to 500. The vertical axis represents time, in seconds. The blue solid line with dots represents the actual start time of each competition round node, the orange dashed line with dots represents the actual end time of the competition, and the gray dashed line and gray dotted line represent the standard start time and standard end time of the standard competition time interval, respectively.

[0058] As shown in the graph, the actual start time curves for all rounds of the competition largely coincide with the standard start time curves for the standard competition time interval. Furthermore, the fluctuations in the actual start times are minimal, remaining within a small random range around 0 seconds, indicating that the start times are strictly controlled near the standard start time. The actual end time curve closely follows the standard end time curve for the standard competition time interval, with a stable curve height of approximately 5400 seconds (i.e., 1.5 hours). The actual end times are slightly lower than the standard end times, with minimal fluctuations, indicating that the competition duration generally meets the preset standard and does not exceed the standard end time.

[0059] In practical implementation, the blockchain network comprises multiple verification nodes, forming a verification node set. A first subset and a second subset of verification nodes are selected from this set. During selection, the node identifier of each verification node in the set is obtained, and the set is sorted lexicographically, resulting in a sorted list of verification nodes. This sorted list is then divided into two parts: the first subset and the second subset, with the same number of nodes in both subsets. During partitioning, verification nodes with odd-numbered indices are assigned to the first subset, and those with even-numbered indices are assigned to the second subset. When the total number of verification nodes in the sorted list is odd, a pre-selected backup verification node is added to the end of the list to make the total number of verification nodes even. Then, the nodes with odd-numbered indices are assigned to the first subset, and the nodes with even-numbered indices are assigned to the second subset. The preset backup verification nodes are designated by the event organizer and do not participate in the actual verification.

[0060] The timestamp field of the block to be verified is sent to the first subset of verification nodes. The timestamp field contains a start timestamp and an end timestamp. The block to be verified is stored in the event data acquisition terminal, which sends the timestamp field of the block to be verified to each verification node in the first subset of verification nodes through the blockchain network. After receiving the timestamp field, each verification node in the first subset of verification nodes retrieves the start timestamp and end timestamp from the timestamp field.

[0061] Each verification node in the first subset of verification nodes obtains the current system time, calculates the first time difference between the start timestamp and the current system time, and the second time difference between the end timestamp and the start timestamp. The first time difference represents the absolute difference between the start timestamp and the current system time, and the second time difference represents the difference between the end timestamp and the start timestamp. The formula for calculating the first time difference is:

[0062]

[0063] in, This indicates the sequential number of the verification nodes in the first subset of verification nodes. The number of nodes increases from 1 to the first subset of verified nodes; Indicates the first The first time difference calculated by each verification node; Indicates the first The start timestamp obtained by each verification node from the timestamp field in the block to be verified; Indicates the first The current system time is read by each verification node; This indicates the operation of taking the absolute value.

[0064] The second time difference is used express, Indicates the first Each verification node obtains the difference between the end timestamp and the start timestamp from the timestamp field of the block to be verified.

[0065] Each verification node in the first subset of verification nodes will Compare with the time tolerance threshold in the global configuration parameters, and Compare with the preset minimum match duration. Less than the time tolerance threshold and When the time exceeds the preset minimum match duration, the first... Each verification node outputs the first verification result as "verification passed". When Not less than the time tolerance threshold or When the duration is not greater than the preset minimum limit of the match duration, the first The first verification result output by each verification node is "verification failed".

[0066] The team identifier field from the block to be verified is sent to the second set of verification nodes. This team identifier field contains the identifiers of the first and second participating teams. The second set of verification nodes then performs a second verification on the team identifier field based on the team identifier whitelist in the global configuration parameters. Each verification node in the second set receives the team identifier field and retrieves the identifiers of the first and second participating teams from it. Each verification node then searches for the first and second participating team identifiers in the team identifier whitelist in the global configuration parameters. The team identifier whitelist is a pre-configured list by the event organizer, recording all allowed participating team identifiers. When both the first and second participating team identifiers are in the team identifier whitelist, each verification node outputs a second verification result of "verification passed." When neither the first nor the second participating team identifier is in the team identifier whitelist, each verification node outputs a second verification result of "verification failed."

[0067] The system receives first verification results from a first subset of verification nodes and second verification results from a second subset of verification nodes. Each verification node in the first subset sends its first verification result to the event data acquisition terminal. Each verification node in the second subset sends its second verification result to the event data acquisition terminal. The event data acquisition terminal counts the number of successful verifications among the received first verification results and the number of successful verifications among the received second verification results. Verification success information is obtained when all first verification results returned by the first subset of verification nodes are successful and all second verification results returned by the second subset of verification nodes are successful. Verification success information is not obtained when at least one first verification result or at least one second verification result is unsuccessful.

[0068] In specific implementation, please refer to Figure 3 This process retrieves the block hash value of the last block on the main blockchain of the event network. The main blockchain is a chain of confirmed blocks linked chronologically within the blockchain network. The last block on the main blockchain is the latest block currently linked to it. The process for obtaining the block hash value of the last block is as follows: The tail pointer of the main blockchain is read, which points to the storage location of the last block. The block hash value field is then read from the block header of the last block on the main blockchain to obtain its hash value.

[0069] The block hash of the last block on the main chain of the competition is used as the preceding block hash of the confirmation block. The confirmation block is the block to be verified that has passed the double-checked verification. A preceding block hash field is set in the block header of the confirmation block, and the block hash of the last block on the main chain of the competition is written into the preceding block hash field of the confirmation block.

[0070] The preceding block hash value, the body data of the confirming block, and the timestamp of the confirming block are packaged into a new block. The body data of the confirming block includes the round number of the current competition round node, the actual start time of the competition, the actual end time of the competition, the list of actual participating teams, and the comparison result field. The timestamp of the confirming block is the system time when the confirming block was generated. During packaging, the preceding block hash value, the body data of the confirming block, and the timestamp of the confirming block are written into the block structure of the new block in sequence. The block structure of the new block includes a block header and a block body. The block header contains the block hash value field of the new block, the preceding block hash value field of the confirming block, and the timestamp field of the confirming block. The block body contains the body data of the confirming block. The block hash value of the new block is calculated using the following formula:

[0071]

[0072] in, This indicates the link number of the new block on the main chain of the competition. The sequence number of the link begins to increase from the next block after the initial block of the main chain. Indicates the first The block hash value of each block; Indicates the first The block hash value of the nth block, the nth This block is the last block on the main chain of the competition. To confirm the preceding block hash value of the block; Indicates the first The main data of the confirmed block in the block body of each block; Indicates the first The timestamp of the confirmed block in the block header of each block; Indicates will byte sequence, byte sequence and The byte sequences are concatenated in chronological order; This indicates the preset cryptographic hash function, using the SHA-256 algorithm. The calculated block hash value of the new block is written to the block hash value field in the block header of the new block.

[0073] The new blockchain is appended to the last block of the main event chain. The linking operation is as follows: the value of the preceding block hash field of the new block is set to the block hash value of the last block on the main event chain; the value of the succeedor block hash field of the last block on the main event chain is set to the block hash value of the new block; and the tail pointer of the main event chain is updated from pointing to the last block to pointing to the new block. In the blockchain network, the succeedor block hash field of the last block on the main event chain was originally empty, but after the update, it points to the block hash value of the new block.

[0074] The node status of the match round node corresponding to the confirmation block in the initial match flow chain is updated from "not executed" to "executed". The main data of the confirmation block contains the round number of the current match round node. The match round node corresponding to the confirmation block is searched in the initial match flow chain, using its round number for matching. Each match round node in the initial match flow chain has a node status field, initially set to "not executed". The node status field of the match round node corresponding to the confirmation block in the initial match flow chain is changed from "not executed" to "executed".

[0075] In some embodiments, when the node status of all rounds in the initial event flow chain is "executed", the flow status of the initial event flow chain is updated to "completed".

[0076] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A blockchain-based method for information management of sports event processes, characterized in that: include: Obtain the global configuration parameters and the list of participating teams for the current event. Based on the global configuration parameters and the list of participating teams, generate an initial event process chain, which contains multiple rounds of competition nodes arranged in chronological order. Based on the list of participating teams and the multiple competition round nodes, an initial schedule time mapping table between the competition rounds and the participating teams is generated. Based on the initial event flow chain and the initial event schedule time mapping table, an event block sequence is generated, and each event block in the event block sequence corresponds to a competition round node; Real-time collection of schedule execution data for each round of the competition; comparison of the schedule execution data with the corresponding standard schedule data in the initial schedule time mapping table field by field; and generation of a block to be verified based on the comparison results. The block to be verified is broadcast to multiple verification nodes in the blockchain network. The multiple verification nodes perform double verification on the block to be verified according to the global configuration parameters to obtain verification pass information. Based on the verification pass information, the block to be verified is associated with the confirmation block and stored on the main chain of the blockchain network, and the process status of the initial event process chain is updated.

2. The blockchain-based information management method for sports event processes according to claim 1, characterized in that, The step of generating an initial schedule time mapping table between competition rounds and participating teams based on the list of participating teams and the multiple competition round nodes includes: Based on the historical match records of each participating team in the list of participating teams, generate a competitive relationship diagram for each participating team; Based on the order of the multiple competition round nodes in the initial event flow chain, extract the preset time period corresponding to each competition round node from the initial event flow chain; Based on the adversarial relationship diagram and the preset time period, the participating teams are assigned pairings for each round of the competition, and the initial schedule time mapping table is generated.

3. The blockchain-based information management method for sports event processes according to claim 1, characterized in that, The step of generating a tournament block sequence based on the initial tournament process chain and the initial tournament schedule time mapping table includes: According to the order of the multiple competition round nodes in the initial event process chain, the team match-up combination and competition time period corresponding to each competition round node are extracted sequentially from the initial competition schedule time mapping table; A first block hash value is generated based on the matchup combinations of the participating teams, and a second block hash value is generated based on the match time period. The hash values ​​of the first block and the second block are concatenated to generate the event block corresponding to each round of the competition. All event blocks are arranged in the order described above to obtain the event block sequence.

4. The blockchain-based information management method for sports event processes according to claim 1, characterized in that, The process involves real-time collection of match execution data for each round, comparing this data field-by-field with the corresponding standard match data in the initial match time mapping table, and generating a block to be verified based on the comparison results. This includes: Extract the standard schedule data corresponding to the current round node from the initial schedule time mapping table. The standard schedule data includes the standard match time interval and the standard list of participating teams. The actual start time, end time, and list of participating teams for the current round of the competition are collected in real time and used as the schedule execution data. The actual start time and end time of the match are compared with the standard match time interval by performing an interval inclusion comparison, and the actual list of participating teams is compared with the standard list of participating teams by performing a member consistency comparison. Based on the results of the interval inclusion comparison and the member consistency comparison, the block to be verified is generated.

5. The blockchain-based information management method for sports event processes according to claim 1, characterized in that, The step of broadcasting the block to be verified to multiple verification nodes in the blockchain network, whereby the multiple verification nodes perform dual verification on the block to be verified according to the global configuration parameters to obtain verification pass information, includes: A first subset of verification nodes and a second subset of verification nodes are selected from the plurality of verification nodes, wherein the first subset of verification nodes and the second subset of verification nodes have the same number of nodes; The timestamp field of the block to be verified is sent to the first subset of verification nodes, and the first subset of verification nodes performs a first verification on the timestamp field according to the time tolerance threshold in the global configuration parameters. The team identifier field in the block to be verified is sent to the second set of verification nodes, and the second set of verification nodes performs a second verification on the team identifier field according to the team identifier whitelist in the global configuration parameters. Receive the first verification result returned by the first subset of verification nodes and the second verification result returned by the second subset of verification nodes. When both the first verification result and the second verification result are verified as passed, obtain the verification pass information.

6. The blockchain-based information management method for sports event processes according to claim 5, characterized in that, The step of sending the timestamp field of the block to be verified to the first subset of verification nodes, and having the first subset of verification nodes perform a first verification on the timestamp field according to the time tolerance threshold in the global configuration parameters, includes: Obtain the timestamp field from the block to be verified, the timestamp field including the start timestamp and the end timestamp; Each verification node in the first subset of verification nodes calculates a first time difference between the start timestamp and the current system time, and a second time difference between the end timestamp and the start timestamp. Each verification node determines whether the first time difference is less than the time tolerance threshold and whether the second time difference is greater than the preset minimum match duration. When both conditions are met, each verification node outputs the first verification result as "verification passed".

7. The blockchain-based information management method for sports event processes according to claim 5, characterized in that, The step of sending the team identifier field from the block to be verified to the second subset of verification nodes, and having the second subset of verification nodes perform a second verification on the team identifier field according to the team identifier whitelist in the global configuration parameters, includes: Obtain the team identifier field from the block to be verified, wherein the team identifier field includes the first participating team identifier and the second participating team identifier; Each verification node in the second verification node subset searches for the first participating team identifier and the second participating team identifier in the team identifier whitelist; When both the first participating team identifier and the second participating team identifier exist in the team identifier whitelist, each verification node outputs the second verification result as verification passed.

8. The blockchain-based information management method for sports event processes according to claim 1, characterized in that, The step of storing the block to be verified as a confirmed block on the main chain of the blockchain network based on the verification pass information, and updating the process status of the initial event process chain, includes: Obtain the block hash value of the last block on the main chain of the blockchain network, and use the block hash value of the last block as the forward block hash value of the confirmed block; The preceding block hash value of the confirmed block, the main data of the confirmed block, and the timestamp of the confirmed block are packaged into a new block, and the new blockchain is appended after the last block; The node status of the competition round node corresponding to the confirmation block in the initial competition process chain is updated from never executed to executed.

9. The blockchain-based information management method for sports event processes according to claim 1, characterized in that, Based on the global configuration parameters and the list of participating teams, an initial event flow chain is generated, including: Based on the total number of rounds in the global configuration parameters and the total number of teams in the list of participating teams, a preset number of round nodes are generated. According to the order of the total number of competition rounds, the preset number of competition round nodes are sequentially connected, and a node hash value is embedded in each competition round node. The node hash value is generated based on the node hash value of the previous competition round node and the round number of the current competition round node. The preset number of competition round nodes, after being connected, are used as the initial competition process chain.

10. The blockchain-based information management method for sports event processes according to claim 4, characterized in that, The interval inclusion comparison includes: when the actual match start time is not earlier than the start time of the standard match time interval and the actual match end time is not later than the end time of the standard match time interval, the interval inclusion comparison is determined to be successful.

Images