Online auction information processing system and method supporting bidding of multiple buyers and sellers

Abstract

The invention provides an online auction information processing system and method supporting bidding of multiple buyers and sellers, and relates to the technical field of electronic commerce. The online auction information processing system and method supporting the bidding of the multiple buyers and sellers comprises the steps that S1, bidding requests of the multiple buyers and sellers are received based on an event-driven network communication mechanism, monotonically increasing logic time sequence identifiers are distributed to each bidding request, and bidding data are written into a memory type ordered queue, and forming a bidding event stream arranged according to a logic time sequence. A multi-source bidding request is received in an event-driven network communication mode, and a monotonically increasing logic time sequence identifier is introduced for each bidding behavior, so that the bidding behaviors form a traceable and comparable logic sequence in a concurrent environment, and interference on matching judgment caused by real physical time jitter is avoided.

Description

Technical Field

[0001] This invention relates to the field of e-commerce technology, specifically to an online auction information processing system and method that supports bidding by multiple buyers and sellers. Background Technology

[0002] The field of e-commerce technology encompasses technologies related to the transaction of goods or services via the internet, covering aspects such as online shopping platforms, auction systems, electronic payments, data encryption and security protection, transaction matching algorithms, and intelligent recommendation systems. With the development of internet technology, e-commerce has become an important part of the global economy and is widely used in various online transactions, B2B, B2C, and C2C models. Among these, the online auction information processing system and method supporting multi-buyer bidding refers to a technical solution for real-time bidding and matching processing based on an e-commerce platform for bidding activities involving multiple buyers and sellers. This system collects and processes bidding information, combining priority ranking and automatic matching algorithms to enable buyers and sellers to quickly complete transactions on the online platform.

[0003] Traditional online auction processing methods for multiple buyers and sellers often rely on arrival time or simple price priority rules for matching. In high-concurrency environments, these methods are susceptible to network latency, request congestion, and system scheduling differences, leading to inconsistent bidding order. Bids submitted around the same time may exhibit different ordering at different processing nodes, resulting in unstable transaction results. Existing sorting methods typically focus on a single dimension, lacking comprehensive consideration of historical transaction fluctuations and market stability. In scenarios of drastic fluctuations or malicious bidding, prices can be manipulated rapidly, and transaction results can frequently reverse, affecting the overall trading order of the platform. During the matching process, common methods rely on locking mechanisms or transaction rollbacks to maintain consistency. When the scale of concurrent requests continues to increase, lock contention and rollback operations can significantly slow down processing speed and even cause matching delays, impacting user experience. Transaction confirmation is often directly determined by a centralized system. Rule changes and result verification heavily rely on the platform's own records. In the event of data disputes or system anomalies, there is a lack of independent and reliable verification evidence, resulting in high post-event verification costs. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides an online auction information processing system and method that supports bidding by multiple buyers and sellers. It solves the problem that traditional online auction processing methods for multiple buyers and sellers rely on arrival time or simple price priority rules for matching, which are easily affected by network latency, request congestion, and system scheduling differences in high-concurrency environments. This makes it difficult to maintain a consistent bidding order, and some bids submitted at close to the same time may show different ordering relationships at different processing nodes, thus leading to unstable transaction results.

[0005] To achieve the above objectives, the present invention provides the following technical solution: an online auction information processing system and method supporting multiple bidders, comprising the following steps:

[0006] S1: The event-driven network communication mechanism receives bidding requests from multiple buyers and sellers, assigns a monotonically increasing logical timing identifier to each bidding request, and writes the bidding data into an in-memory ordered queue to form a bidding event stream arranged in logical timing.

[0007] S2: Calculate the sorting weights for the bidding data in the bidding event stream according to the following priority function: ;

[0008] in:

[0009] This is the normalized value of the bid-ask spread;

[0010] The time weight is calculated based on the logical time sequence identifier;

[0011] This is a stability adjustment factor calculated based on historical trading volatility.

[0012] These are preset or dynamically updated weight parameters;

[0013] A deterministic sorting result is generated based on the sorting weights.

[0014] S3: Based on the deterministic sorting results, a lock-free matching execution mechanism is adopted to determine whether the bid-ask spread meets the transaction conditions without rolling back the confirmed matching results, and to generate a transaction record.

[0015] S4: Deploy the transaction condition judgment rules to the blockchain network in the form of smart contracts. Before generating a transaction record, verify the transaction conditions on the chain through the smart contract, and write the transaction hash value after the verification is passed.

[0016] S5: Confirms the transaction status based on the on-chain verification results and returns the matching results to the corresponding buyers and sellers.

[0017] Preferably, the logical timing identifier is generated based on Lamport Clock or Hybrid Logical Clock.

[0018] Preferably, the stability adjustment factor Vadj is calculated based on the standard deviation of the most recent N transaction prices.

[0019] Preferably, the lock-free matching execution mechanism is implemented based on CAS atomic operations.

[0020] Preferably, an online auction information processing system supporting multiple bidders includes the following modules: a bidding acquisition module, which receives bidding information from multiple bidders and writes it in a time-series manner according to an event-driven network communication mechanism, generating a bidding event stream arranged in logical time sequence;

[0021] The matching decision module, based on the bidding event flow, sorts the bidding information according to the priority function and generates a deterministic sorting result. It uses a lock-free matching execution mechanism to determine the transaction and generate a transaction record.

[0022] The on-chain verification module deploys the transaction condition judgment rules to the blockchain network and verifies the transaction conditions on-chain through smart contracts. After successful verification, the transaction hash value is written to the blockchain.

[0023] The results feedback module confirms the transaction status based on the on-chain verification results and returns the matching results to the corresponding buyers and sellers.

[0024] Preferably, the bidding acquisition module includes:

[0025] The data access submodule receives bidding information from multiple buyers and sellers;

[0026] The timing identifier allocation submodule assigns a monotonically increasing logical timing identifier to each bidding request and writes the bidding data into an in-memory ordered queue.

[0027] The data storage submodule stores the standardized bidding information in a structured manner, forming a bidding event stream.

[0028] Preferably, the matching decision module includes:

[0029] The sorting submodule sorts the bidding information according to the priority function and generates a deterministic sorting result;

[0030] The lockless matching execution submodule determines whether the bidding information meets the transaction conditions and generates a transaction record.

[0031] Preferably, the on-chain verification module includes:

[0032] The smart contract execution submodule deploys the rules for determining transaction conditions and verifies the transaction conditions on-chain through smart contracts.

[0033] Preferably, the result feedback module includes:

[0034] The feedback submodule confirms the transaction status based on the on-chain verification results and returns the matching results to the corresponding buyers and sellers.

[0035] Preferably, the bidding information storage module is a memory-based ordered queue to ensure that the bidding information is arranged in logical time sequence.

[0036] This invention provides an online auction information processing system and method that supports multiple buyers and sellers bidding. It has the following beneficial effects:

[0037] This invention receives multi-source bidding requests through event-driven network communication and introduces a monotonically increasing logical sequence identifier for each bidding action. This enables bidding actions to form a traceable and comparable logical order in a concurrent environment, avoiding interference from real physical time jitter in matching decisions. Bidding data has a clear sequential relationship when entering the processing flow. Based on this, the bidding data is written into an in-memory ordered structure to ensure data consistency and response efficiency in high-frequency write and read scenarios. A comprehensive ranking weight is constructed around the bidding event stream, including price differences, time weights, and historical fluctuation stability, so that bidding ranking is no longer limited to a single price. Instead of focusing on a simple time dimension, it uses multi-factor constraints to form deterministic results, mitigating the impact of extreme pricing or instantaneous congestion on the fairness of transactions. During the matching and execution phase, the matching process is maintained in a linear manner by judging the transaction conditions one by one without rolling back the confirmed results. This reduces the performance loss caused by repeated judgments and state rollbacks under concurrent conflicts and improves throughput stability in high-concurrency scenarios. At the same time, a blockchain-based condition verification process is introduced before transaction confirmation, transforming key transaction rules into verification logic that cannot be arbitrarily changed. This ensures that the transaction results have verifiability and tamper-proof attributes from the generation stage, reducing the cost of subsequent dispute resolution. Attached Figure Description

[0038] Figure 1 This is a schematic diagram of the steps of the present invention;

[0039] Figure 2 This is a system block diagram of the present invention. Detailed Implementation

[0040] 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, and 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.

[0041] Example:

[0042] like Figure 1-2 As shown, this embodiment of the invention provides an online auction information processing system and method that supports multiple buyers and sellers bidding, including the following steps:

[0043] S1: The event-driven network communication mechanism receives bidding requests from multiple buyers and sellers, assigns a monotonically increasing logical timing identifier to each bidding request, and writes the bidding data into an in-memory ordered queue to form a bidding event stream arranged in logical timing.

[0044] During system operation, requests from different buyers and sellers are first identified based on network event trigger signals. Each request is then broken down into basic fields such as bid direction, bid range, bid quantity range, and source identifier. Subsequently, a sequential counting module is invoked in memory to generate logical time sequence numbers. These numbers are incremented based on an existing number sequence, with the increment size adjusted according to the current system load. For example, a smaller increment size is used in request-intensive sections, and a larger increment size is used in request-sparse sections. After numbering, these numbers are combined with the bidding fields to form a structured record. Before writing, each field undergoes range validation, such as determining whether the bid falls within an allowed price range and whether the quantity is within a preset range. Once validation is successful, the record is written to an in-memory ordered structure. This structure is sorted and maintained according to the logical time sequence numbers. If multiple requests arrive simultaneously, they are inserted into different node positions based on their number size. Through multiple insertions, a continuously arranged data set is formed, ultimately creating a sequentially traversable set of bidding events in memory.

[0045] S2: Calculate the sorting weights for the bidding data in the bidding event stream according to the following priority function: ;

[0046] in:

[0047] This is the normalized value of the bid-ask spread;

[0048] The time weight is calculated based on the logical time sequence identifier;

[0049] This is a stability adjustment factor calculated based on historical trading volatility.

[0050] These are preset or dynamically updated weight parameters;

[0051] A deterministic sorting result is generated based on the sorting weights.

[0052] When reading the event set, the system extracts the buy and sell price ranges from each bidding record, compares the ranges of both buyers and sellers, calculates the base price difference using the median difference between the ranges, and then converts this base price difference to the reference price range width to obtain a normalized price difference value. This normalized result is divided into low, medium, and high segments based on the proportion of the range it falls into, with different segments corresponding to different numerical levels. Simultaneously, the system reads the logical time sequence number, compares it with the total length of the set, and calculates the time weight value based on the current position's proportion. Earlier positions correspond to higher weight segments, and later positions correspond to lower weight segments. Then, the system selects several consecutive transaction ranges from the historical transaction record set and calculates the dispersion of the median of each transaction range. A stability adjustment factor is mapped to the range of dispersion amplitude; for example, concentrated volatility corresponds to higher stability segments, and dispersed volatility corresponds to lower stability segments. The system then multiplies these three types of values ​​by pre-set weight parameters, which are set within multiple levels based on the business stage. These weighted sums form a sorting reference value. After all records have been calculated, they are rearranged according to this reference value to obtain a fixed-order arrangement.

[0053] S3: Based on the deterministic sorting results, a lock-free matching execution mechanism is adopted to determine whether the bid-ask spread meets the transaction conditions without rolling back the confirmed matching results, and to generate a transaction record.

[0054] When reading the sorted records, the system loads the bidding data one by one in the order of arrangement. For each record, it first parses the buy / sell direction identifier, then retrieves the matching set of opposing records from memory. It determines whether there is an intersection between the two bids by comparing intervals. The intersection width is calculated by the difference between the upper and lower limits of the interval. This difference is compared with a preset transaction interval threshold, which is derived from the statistical range of historical transaction intervals and divided into multiple level segments. If the intersection width falls into the allowed segment, the system proceeds to the quantity processing step. In the quantity processing step, the quantity intervals of both parties are extracted, and the tradable quantity segment is formed by taking the overlapping part of the intervals. Then, the transaction identifier is written using an atomic state comparison method. Before writing, the current record state is read and compared with the expected state. If they match, the writing is completed; otherwise, the current record is skipped. Records that have been written do not participate in subsequent judgments. As processing progresses, a set of transaction entries containing price and quantity intervals is gradually generated in memory.

[0055] S4: Deploy the transaction condition judgment rules to the blockchain network in the form of smart contracts. Before generating a transaction record, verify the transaction conditions on the chain through the smart contract, and write the transaction hash value after the verification is passed.

[0056] After generating a transaction entry in memory, the system organizes the key fields in the entry, extracting the price range identifier, quantity range identifier, and logical number summary information. This information is then converted into a unified parameter format. During parameter generation, the length of each field is normalized, and the parameters are concatenated in a predetermined order to form a verification parameter set. This set is then passed to the on-chain rule execution environment. During rule execution, each parameter is compared against its corresponding range; for example, whether the price range falls within the registration range and whether the quantity range is within the allowed range. Each comparison generates a corresponding marker result. When all marker results are within the allowed range, the system performs a summary calculation on the parameter set. The summary value is generated through an encoding mapping method and written to the on-chain storage area, forming an index record associated with the transaction entry.

[0057] S5: Confirms the transaction status based on the on-chain verification results and returns the matching results to the corresponding buyers and sellers.

[0058] After on-chain verification is completed, the system receives the returned verification information, parses the status identifier segment and summary index contained therein, writes the parsing result into the corresponding transaction entry, performs range conversion on the status field of the transaction entry to change it from the pending segment to the confirmation segment, and then generates a feedback data structure based on the buyer and seller identifiers recorded in the transaction entry. The feedback data structure includes the transaction price segment, quantity segment, and summary index field. Before sending, a consistency check is performed on this structure, including field integrity checks and range logic comparisons. After the check passes, the feedback data is sent to the corresponding entity through the communication interface, completing this round of processing.

[0059] The logical timing identifier is generated based on Lamport Clock or Hybrid Logical Clock.

[0060] In scenarios where multiple buyers and sellers submit requests concurrently, the system first maintains a set of local logical time variables. Upon receiving an external bidding request, it reads the current logical time state, marks the request event, and compares the local logical time with the time reference information carried in the request. The larger value is taken as the base time reference, and then an increment operation is performed on this basis. The increment is selected according to the current event density range of the system. For example, a smaller increment is used when the number of events per unit time is in a low-density range, and a relatively larger increment is used in a high-density range, thus forming a new logical time sequence value. If a hybrid logic approach is adopted, a physical time segment is added to the logical time, and the physical time is processed into intervals and mapped to discrete levels. Together with the logical time, they form a composite identifier. During the generation process, the composite identifier of the previous event is compared to determine whether it satisfies the monotonically increasing relationship. If not, it is corrected by incrementing the logical part again. Then, the identifier is bound to the bidding request for storage. For example, in multiple consecutive buyer bids, the first request is assigned a smaller interval identifier, and the later request is assigned a larger interval identifier, ultimately forming a sortable event identifier result.

[0061] The stability adjustment factor Vadj is calculated based on the standard deviation of the most recent N transaction prices.

[0062] The system maintains a set of recent transaction records, updated in chronological order. Each time a new transaction record is added, the oldest record is removed from the set to keep its size within a preset range. During calculation, the median price range for each transaction record is first extracted from the set. These medians are then aggregated, and their average level is calculated by summing the medians and dividing by the number of records. Next, the difference between each transaction price median and the average level is calculated. The absolute value of the difference is taken as the deviation. All deviations are squared, summed, and then divided by the number of records. The variance approximation is obtained by taking the number of transactions. The square root of the variance approximation is then used to obtain the volatility index. This index is divided into stable, moderately volatile, and highly volatile zones based on the range in which its value falls. Different zones correspond to different adjustment parameter levels. For example, a smaller volatility range is mapped to a higher stability level, while a larger volatility range is mapped to a lower stability level. In practical examples, the median of several transaction prices can be selected for calculation to obtain a volatility result in a moderate range. Based on this, the corresponding adjustment parameter value is determined, and finally, a stability adjustment result is generated for subsequent calculations.

[0063] The lock-free matching execution mechanism is implemented based on CAS atomic operations.

[0064] During the matching execution phase, the system maintains an independent state identifier for each record eligible for matching. This state identifier uses discrete intervals to represent different processing stages. Before executing the update, the processing thread first reads the current state value from memory and compares it with the expected state interval. Only when the read state falls into the interval that allows updates will the next operation proceed. Subsequently, a new state value is constructed. This new state value is selected from multiple candidate intervals based on the matching judgment result. During the writing process, the old state and the new state are submitted simultaneously through atomic comparison. When the actual state in memory matches the submitted old state, the write operation is completed; otherwise, the write fails and the state is read again. In scenarios of continuous competition, different threads perform the above comparison and write process on the same record, completing the state advancement through multiple attempts. For example, when a buy and sell quote is read by multiple matching threads at the same time, only the thread that completes the state replacement first can successfully update. The remaining threads terminate their operation after recognizing the state change during the comparison phase, ultimately forming a stable matching processing result in the state set.

[0065] An online auction information processing system supporting multiple bidders includes the following modules: a bidding acquisition module, which receives bidding information from multiple bidders and writes it in a time-series manner according to an event-driven network communication mechanism, generating a bidding event stream arranged in logical time sequence;

[0066] After receiving bidding information from multiple buyers and sellers, the bidding acquisition module first processes the bidding information according to a time-series mechanism based on an event-driven network communication mechanism. Specifically, each bidding information is timestamped and compared with the current system's logical clock. If the timestamp of the bidding information is smaller than the system's internal timestamp, the system increments it to ensure that the bidding information is arranged in logical time sequence and written sequentially. The writing process ensures data order by synchronizing the internal and external clock states. Each time bidding information is received, the system generates a new event identifier based on the current logical time sequence. The new identifier is compared with existing event identifiers; if the new event identifier is larger, it is stored in chronological order. For example, when multiple buyers submit bids simultaneously, the system adjusts the increment of the local logical clock to ensure that the bidding requests are recorded in the correct time sequence, ultimately generating a series of sortable bidding event streams.

[0067] The matching decision module, based on the bidding event flow, sorts the bidding information according to the priority function and generates a deterministic sorting result. It uses a lock-free matching execution mechanism to determine the transaction and generate a transaction record.

[0068] After receiving the bidding event stream, the matching decision module first sorts the bidding information according to a preset priority function. This priority function depends on multiple factors, such as price and time. The sorting process is achieved by calculating the priority value of each bidding event. The priority value is typically obtained through a weighted calculation, using the following formula:

[0069]

[0070] in, These are weighting coefficients. Price and time represent the bid and request times of the buyer and seller, respectively. Other factors may include user credit rating. After prioritization, the system uses a lock-free concurrent operation mechanism to determine which bids can be matched. Specifically, it uses atomic operations (CAS, Compare-and-Swap) to update the state, ensuring the accuracy of the matching results in a concurrent environment. Finally, the system generates a transaction record based on the ranking results and the matching criteria, outputting the final transaction information. For example, when a buyer with a bid price of 500 yuan matches a seller with a bid price of 450 yuan, the matching decision module will prioritize the bids based on price, then use a lock-free mechanism to decide whether to complete the match and generate a transaction record.

[0071] The on-chain verification module deploys the transaction condition judgment rules to the blockchain network and verifies the transaction conditions on-chain through smart contracts. After successful verification, the transaction hash value is written to the blockchain.

[0072] After receiving a transaction record, the on-chain verification module deploys the transaction condition judgment rules to the blockchain network and verifies the transaction conditions on-chain through a smart contract. The smart contract confirms the validity of the transaction information according to preset rules. The specific process includes: writing the transaction information into the smart contract; the contract verifying whether the transaction meets the rules according to the set conditions, such as whether the bids of the buyer and seller meet the minimum / maximum transaction price requirements, and whether there is a compliant time window. If all conditions are met, the contract automatically returns a verification result. After verification, the system writes the transaction hash value into the blockchain, thereby ensuring the immutability and traceability of the transaction information. For example, when a bid is completed, the smart contract checks whether the buyer's price is higher than the seller's price and verifies the legality of the timestamp. If the rules are met, it returns a verification result, and finally records the transaction hash value in the blockchain, forming an immutable transaction certificate.

[0073] The results feedback module confirms the transaction status based on the on-chain verification results and returns the matching results to the corresponding buyers and sellers.

[0074] The result feedback module confirms the transaction status based on on-chain verification results. The system verifies the validity of a transaction by querying the transaction hash value stored in the blockchain network. If the verification result is successful, the system will further send a matching result notification to the relevant buyers and sellers, informing them of the transaction status and specific details of the transaction. The feedback process includes: first, retrieving the hash value of the transaction from the blockchain to determine if the transaction was successful; if the transaction is successful, the transaction information is returned to both the buyer and seller; if the transaction fails, a failure message is returned, requiring a resubmission of the bidding request. Through this process, both buyers and sellers can obtain the transaction status in real time and take further actions based on the feedback information. For example, when a bidding transaction is successfully verified, the system sends a transaction notification to the buyer and seller through the result feedback module, including detailed information such as the transaction price, quantity, and time.

[0075] The bidding acquisition module includes:

[0076] The data access submodule receives bidding information from multiple buyers and sellers;

[0077] During system operation, multiple buyers and sellers submit their bidding requests through network interfaces. The data access phase first involves decomposing the received raw request content into fields, including at least an identity field, a price field, and fields related to the submission order. After decomposition, each field undergoes format validation by comparing its length to a preset range and its type to conform to agreed-upon rules. For example, for the price field, it's first determined whether it's a numerical value, then compared to a reference range maintained by the system. If it falls within a reasonable range, the field value is retained; otherwise, it's discarded or reset. After field validation, multiple bidding requests received within the same time period are grouped based on the source identifier and access channel identifier. A preliminary queue is formed by comparing the order in which requests enter the system. Requests are then arranged in the queue according to their receiving order. During this arrangement, the current access buffer's capacity is continuously read. When the capacity is in a lower range, data is written directly; when the capacity is in a higher range, it's written in batches. These steps create a set of bidding access data that can be passed to downstream modules.

[0078] The timing identifier allocation submodule assigns a monotonically increasing logical timing identifier to each bidding request and writes the bidding data into an in-memory ordered queue.

[0079] After completing the basic access to bidding information, the system performs a timing identifier generation operation for each bidding request. First, it reads the logical sequence baseline value maintained by the system. This baseline value comes from the sequence state after the most recent successful write operation. When generating a new identifier, the baseline value is compared with the reference sequence identifier carried by the current request. If the reference sequence identifier is in a lower range, the new identifier is generated by incrementing the baseline value. The increment is adjusted according to the range of the number of requests per unit time. For example, when the number of requests is in a medium range, a fixed step increment is used, and when the number of requests is in a higher range, a larger step increment is used. The increment calculation process can be represented as adding an increment value after range mapping to the original baseline value. Then, the generated logical timing identifier is combined with the corresponding bidding data to form a record unit. Before writing to the ordered structure in memory, the system compares the timing identifier of the record unit with the record at the tail of the queue. If the order relationship is true, it is directly inserted. If not, it is adjusted by incrementing the timing identifier again. After adjustment, the comparison is repeated until the order condition is met. Finally, the bidding data is written to the ordered queue maintained by the memory structure.

[0080] The data storage submodule stores the standardized bidding information in a structured manner, forming a bidding event stream.

[0081] After writing to the memory queue, the system performs a normalization process on the bidding records. This process first reads the bidding records sequentially from the ordered memory structure, maps the fields in each record uniformly (e.g., mapping field names from different sources to internal unified identifiers), and performs range processing on the field values, mapping continuous values ​​to discrete level ranges. During the mapping process, the level is determined by comparing the original field values ​​with the preset segmentation range boundaries. Then, the mapped fields are reassembled according to a predefined structure template. The positions of each field in the template are fixed, and the structure is assembled by filling in each item. After the assembly is completed, the generated data structure is checked for integrity by checking each field for missing items. Data that passes the check is written to a persistent storage buffer and forms a continuous data stream according to the logical time sequence identifier. In this data stream, the time sequence relationship between adjacent records remains consistent, thus forming a set of bidding events that can be read and processed by subsequent modules.

[0082] The matching decision module includes:

[0083] The sorting submodule sorts the bidding information according to the priority function and generates a deterministic sorting result;

[0084] After receiving the bidding event set output by the preceding module, the system first reads the set of basic attributes that can be used for sorting from each bidding record. This attribute set includes at least the bid attribute, submission order attribute, and source identifier attribute. Then, each attribute is broken down and transformed into computable data items. For example, the bid attribute is transformed into a numerical range label that can participate in the calculation, and the submission order attribute is mapped to a continuously increasing sequence label. Based on this, a priority calculation process is constructed. During the calculation, different weight coefficients are assigned to different attributes to achieve weighted processing. The weight coefficients are set based on the frequency range of each attribute in the historical matching samples. When the frequency of a certain attribute is in a high range, its corresponding weight value is adjusted upwards, and vice versa. Then, by multiplying each attribute value with its corresponding weight and summing the results, the priority calculation result of each bidding record is obtained. After the calculation is completed, the priority results of all bidding records are compared. The relationship between them is determined by pairwise comparison. When the priority value of a record falls into a relatively high range, it is ranked higher. If they are in similar ranges, their submission order attribute is further compared. The above comparison and adjustment process is repeated to finally form a sorted output result that maintains a consistent order relationship when executed multiple times under the same input conditions.

[0085] The lockless matching execution submodule determines whether the bidding information meets the transaction conditions and generates a transaction record.

[0086] After the sorting results are generated, the system reads the bidding records sequentially and enters the concurrent matching judgment stage. In this stage, shared resources are not locked; instead, the judgment process is completed by atomically comparing the status fields of the bidding records. Specifically, the system first extracts the bid data from the current record to be processed and the bid data from the counterparty's record, and substitutes them into a preset transaction judgment expression for comparison. During the comparison, preliminary screening is performed by determining whether one party's bid falls within the other party's acceptable range. If the comparison result is within the acceptable range, the system proceeds to the next step of status verification. During status verification, the processing flag of the current bidding record is read and its... The system compares the record with a baseline state value maintained in memory. If they match, a state update attempt is performed atomically. If the update succeeds, the record is considered to have entered the transaction generation process. If it fails, it means that the state has been modified by other processes. The system marks the record as skipped and continues to process the next record. In the transaction generation process, the system combines the records of both parties involved in the comparison, extracts their key fields, and splices them according to a preset structure. During the splicing process, field-by-field validation is used to avoid missing items. Finally, a transaction data record containing information of both parties is formed and written into the transaction record set for subsequent modules to continue processing.

[0087] The on-chain verification module includes:

[0088] The smart contract execution submodule deploys the rules for determining transaction conditions and verifies the transaction conditions on-chain through smart contracts.

[0089] Firstly, the smart contract deployed on-chain contains rules for determining transaction conditions. These rules mainly cover the basic elements of auction transactions, such as price range, trading volume, and time conditions. When the contract executes, it first reads the transaction conditions stored on-chain and substitutes the corresponding information from the auction records into the determination logic for comparison and verification. Specifically, the contract retrieves the price field in each auction record and compares it with the set minimum transaction price. If the price meets or exceeds the set threshold, it proceeds to the next condition determination step, such as trading volume conditions and time conditions. If all conditions are met, the smart contract automatically executes transaction confirmation, generates a transaction record, and triggers subsequent processes, such as fund transfer or goods delivery. The contract execution process is entirely based on on-chain data, ensuring the transparency and immutability of the process. Through calculation and logical verification, the smart contract avoids human intervention, reduces risks and errors, and ultimately generates an unalterable transaction record, ensuring the fairness and security of each transaction.

[0090] The result feedback module includes:

[0091] The feedback submodule confirms the transaction status based on the on-chain verification results and returns the matching results to the corresponding buyers and sellers.

[0092] After on-chain verification is complete, the system first reads the verification result from the on-chain smart contract. After the contract is executed, it returns an identifier indicating whether the current bid meets the transaction conditions. The feedback submodule first parses this identifier and determines whether to return a result to the buyer and seller based on different transaction status identifiers. If the verification result shows that the transaction conditions are met, the system generates a transaction confirmation message, which includes relevant information of the buyer and seller, transaction price, transaction volume, transaction time, etc., and sends this information to the corresponding buyer and seller via the network. If the verification result shows that the transaction conditions are not met, the system generates corresponding failure feedback according to preset rules, informing the buyer and seller that the current bid has not been executed and providing the corresponding reason for the failure. The entire process is completed automatically by the system, and the feedback information is real-time and accurate. The buyer and seller make subsequent decisions or operations based on the feedback information.

[0093] The bidding information storage module is a memory-based ordered queue, ensuring that the bidding information is arranged in logical time sequence.

[0094] In an in-memory ordered queue, bidding information is arranged according to logical time sequence. First, before each bidding record enters the storage queue, it needs to undergo field decomposition and validation. Validation items include the format and validity of data such as bid price, submission time, and transaction conditions. Bidding records that pass validation are inserted into the in-memory queue according to timestamps or other logical order identifiers. The queue ensures that the order relationship is not disrupted during storage. If new information enters, the system compares the timestamp of the new information with other data in the existing queue. If the timestamp of the new information is earlier, it is inserted at the front of the queue; if it is later, it is inserted at the end of the queue, ensuring that the bidding information is arranged in order of submission time or preset conditions. The data in the queue is dynamically adjusted as needed to ensure that the system can read the latest bidding information in real time, providing real-time and accurate data support and avoiding delays or errors in bidding information. Finally, the bidding records that have been effectively validated and stored form a stable data stream in logical time sequence for use by subsequent modules.

[0095] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for processing online auction information that supports bidding by multiple buyers and sellers, characterized in that, Includes the following steps: S1: The event-driven network communication mechanism receives bidding requests from multiple buyers and sellers, assigns a monotonically increasing logical timing identifier to each bidding request, and writes the bidding data into an in-memory ordered queue to form a bidding event stream arranged in logical timing. S2: Calculate the sorting weights for the bidding data in the bidding event stream according to the following priority function: ; in: This is the normalized value of the bid-ask spread; The time weight is calculated based on the logical time sequence identifier; This is a stability adjustment factor calculated based on historical trading volatility. These are preset or dynamically updated weight parameters; A deterministic sorting result is generated based on the sorting weights; S3: Based on the deterministic sorting results, a lock-free matching execution mechanism is adopted to determine whether the bid-ask spread meets the transaction conditions without rolling back the confirmed matching results, and to generate a transaction record. S4: Deploy the transaction condition judgment rules to the blockchain network in the form of smart contracts. Before generating a transaction record, verify the transaction conditions on the chain through the smart contract, and write the transaction hash value after the verification is passed. S5: Confirms the transaction status based on the on-chain verification results and returns the matching results to the corresponding buyers and sellers.

2. The online auction information processing method supporting multiple buyer and seller bidding according to claim 1, characterized in that: The logical timing identifier is generated based on Lamport Clock or Hybrid Logical Clock.

3. The online auction information processing method supporting multiple buyer and seller bidding according to claim 1, characterized in that: The stability adjustment factor Calculated based on the standard deviation of the most recent N transaction prices.

4. The online auction information processing method supporting multiple buyer and seller bidding according to claim 1, characterized in that: The lock-free matching execution mechanism is implemented based on CAS atomic operations.

5. An online auction information processing system supporting multiple buyer and seller bidding, characterized in that, It includes the following modules: a bidding acquisition module, which receives bidding information from multiple buyers and sellers, and writes it in a time-series manner according to the event-driven network communication mechanism to generate a bidding event stream arranged in logical time sequence; The matching decision module, based on the bidding event flow, sorts the bidding information according to the priority function and generates a deterministic sorting result. It uses a lock-free matching execution mechanism to determine the transaction and generate a transaction record. The on-chain verification module deploys the transaction condition judgment rules to the blockchain network and verifies the transaction conditions on-chain through smart contracts. After successful verification, the transaction hash value is written to the blockchain. The results feedback module confirms the transaction status based on the on-chain verification results and returns the matching results to the corresponding buyers and sellers.

6. The online auction information processing system supporting multiple buyer and seller bidding according to claim 5, characterized in that: The bidding acquisition module includes: The data access submodule receives bidding information from multiple buyers and sellers; The timing identifier allocation submodule assigns a monotonically increasing logical timing identifier to each bidding request and writes the bidding data into an in-memory ordered queue. The data storage submodule stores the standardized bidding information in a structured manner, forming a bidding event stream.

7. The online auction information processing system supporting multiple buyer and seller bidding according to claim 5, characterized in that: The matching decision module includes: The sorting submodule sorts the bidding information according to the priority function and generates a deterministic sorting result; The lockless matching execution submodule determines whether the bidding information meets the transaction conditions and generates a transaction record.

8. The online auction information processing system and method supporting multiple buyer and seller bidding as described in claim 5, characterized in that: The on-chain verification module includes: The smart contract execution submodule deploys the rules for determining transaction conditions and verifies the transaction conditions on-chain through smart contracts.

9. The online auction information processing system and method supporting multiple buyer and seller bidding according to claim 5, characterized in that: The result feedback module includes: The feedback submodule confirms the transaction status based on the on-chain verification results and returns the matching results to the corresponding buyers and sellers.

10. The online auction information processing system and method supporting multiple buyer and seller bidding according to claim 5, characterized in that: The bidding information storage module is a memory-based ordered queue, ensuring that the bidding information is arranged in logical time sequence.

Images