Electronic ticket ordering and payment application system based on block chain

Abstract

The invention discloses an electronic ticket ordering and payment application system based on a block chain, relates to the technical field of block chains, and is used for ticket business whole-process digital management, and a user interaction module supports multi-terminal operation and information management; the block chain order management module is responsible for order chaining and state updating; the multi-mode payment module supports double-track payment and encrypted transmission; the comprehensive matching module is linked with the block chain order management module and comprises a meal subsystem, a tourism subsystem, a hotel reservation subsystem and the like, and the passenger ticket verification module realizes multi-mode verification; the data storage module stores key data; and the intelligent contract scheduling module automatically executes the pre-deployed contract. The problems that an existing system is poor in data safety, low in efficiency and insufficient in adaptability are solved, ticket transaction safety and process automation are improved, data synchronization is guaranteed, multiple languages and multiple currencies are supported, user privacy is protected, multiple scenes are adapted, and travel and supervision requirements are met.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchain, and particularly relates to an electronic ticket ordering and payment application system based on blockchain. BACKGROUND

[0002] With the digital transformation of air and rail passenger transport, electronic tickets have gradually replaced traditional paper tickets and become the mainstream travel credentials. Although the early electronic ticket ordering and payment system realized ticket query, reservation and third-party payment functions, it adopted a centralized architecture design, which had data security and information tampering risks. User order information and personal identity data were stored in an information processing server. Once the server was attacked by hackers or suffered internal operation errors, data leakage or malicious tampering of orders would easily occur. At the same time, the payment process relied on a single payment center server, the fund flow path was not transparent, users could not trace the payment status, and the order status update of refund, change and other operations was prone to delay, which brought inconvenience to users' travel. In addition, such a system did not integrate blockchain technology, and could not realize permanent evidence of order data. When ticket disputes occurred, there was a lack of tamper-proof evidence chain support, and the user's rights protection cost was high.

[0003] Some existing ticket systems attempt to introduce blockchain technology, which has improved data evidence and payment security, but still has functional and adaptability shortcomings. On the one hand, the blockchain application of such a system is limited to order data chaining, and a complete smart contract mechanism is not designed for the whole life cycle of ticketing (ordering-payment-verification-refund and change), which results in manual intervention in key links such as refund fee calculation and change ticket verification, and low efficiency. On the other hand, the system's comprehensive supporting service integration is insufficient, only covering basic meal and hotel reservations, without including convenient payment, cross-border payment and other diversified needs, and without solving the data synchronization problem. When users query the remaining tickets through the airline's self-operated platform and OTA platform at the same time, data inconsistency may occur, resulting in the situation that "tickets have been displayed but cannot be booked", which affects user experience. In addition, the single user privacy protection measures of such a system are simple, and simple encryption storage is used without combining zero-knowledge proof, data desensitization and other technologies, which is difficult to meet the strict needs of user privacy protection.

[0004] With the growth of cross-border travel demand and the development of digital economy, the limitations of existing systems are further highlighted. On the one hand, traditional centralized systems cannot support multi-agent collaborative scenarios. The data interaction between airlines, railway departments, payment institutions and service providers relies on interface connection, and there is a problem of data island. The settlement period is long (usually T+1 or longer), and the efficiency of fund circulation is low. On the other hand, cross-border ticket ordering faces language barriers and currency conversion difficulties. The existing system mainly supports Chinese and RMB payment, which is not convenient for overseas users. There is a lack of compliant digital currency payment channels, which cannot meet the payment needs under the digital economy. At the same time, the regulatory authorities have increasingly high requirements for the transparency and traceability of ticket data. The existing system cannot provide real-time and tamper-proof regulatory data interface, which is not conducive to regulatory audit. These problems make it difficult for the existing aviation and railway electronic ticket system to meet the needs of users for safe, efficient and convenient travel, and there is an urgent need for a full-process solution based on blockchain technology to realize the decentralized control and multi-scenario adaptation of ticket transactions. SUMMARY

[0005] The electronic ticket ordering and payment application system based on blockchain proposed in the present application solves the problems mentioned in the prior art.

[0006] In order to achieve the above purpose, the present application adopts the following technical solutions:

[0007] An electronic ticket ordering and payment application system based on blockchain includes the following modules:

[0008] User interaction module: provides multi-terminal operation entry for users, supports mobile phone APP (iOS / Android system, version >=10.0 / 12.0), PC terminal (browser compatible Chrome >=90.0, Edge >=88.0), and smart terminal (airport / station self-service machine, face recognition terminal) access. The module supports ticket query (filtering by trip, date, cabin / seat type, query result loading time <=0.8 seconds), ordering (automatically filling user information after selecting ticket, supporting batch ordering of 1-10 people), changing (changing date / train / flight, real-time display of remaining tickets and price difference), and ticket refund (triggering smart contract pre-verification after submitting application) operations; built-in user information management unit, storing desensitized user information (name, certificate number hash value, contact information encrypted storage), supporting information modification and authorization management (such as authorizing others to order on behalf of), and operation log real-time synchronization to blockchain storage module;

[0009] Blockchain order management module: responsible for the whole life cycle data of the order on the chain and management, including order generation unit, state update unit, query unit; order generation unit receives the subscription request of user interaction module, integrates the itinerary (departure / destination, date, time, cabin / seat), user, payment information, generates a unique order number (uses UUID+block height of blockchain combination coding), and writes into the blockchain after processing by SHA-256 hash algorithm; the state update unit updates the order state in real time according to the ticket use process (to be paid→paid→to be verified→verified→completed / refunded / changed), and the state change needs to be verified by at least 3 consensus nodes; the query unit supports users to query orders through order number, certificate number hash value, mobile phone encrypted value, and the query result includes complete state flow record and corresponding block hash, and the query response time is ≤1 second; when the state changes to "paid", send service trigger instruction to the comprehensive supporting system;

[0010] Multi-modal payment module: supports dual-track payment of legal currency and digital currency, including payment method selection unit, encrypted transmission unit, and payment verification unit. Legal currency payment supports bank cards (UnionPay, Visa, MasterCard, using EMV chip encryption standard), third-party payment (Alipay, WeChat payment, connecting official API, payment interface encryption level ≥ TLS1.3); digital currency payment supports mainstream compliant digital currency (such as digital RMB, connecting the interface of the central bank digital currency research institute), using offline payment and online synchronization combination mode; the encrypted transmission unit uses AES-256 encryption for payment instructions (amount, account information, order number), and payment data is only visible to payment parties and necessary consensus nodes; the payment verification unit receives the payment result feedback from the payment center, generates a payment voucher and uploads it to the chain, and the payment response time is ≤3 seconds, and when the payment fails, it automatically triggers the refund pre-application and notifies the user;

[0011] Ticket verification module: realizes multi-scene quick verification of tickets, including verification method adaptation unit, identity verification unit, and result feedback unit. Verification methods support dynamic two-dimensional code (updated every minute, using QRCode format, containing order hash and time limit parameter), NFC near field communication (supports mobile phone NFC, physical card simulation, verification distance ≤5cm), and face recognition (connects to the public security face database, recognition speed ≤0.5 seconds, accuracy rate ≥99.8%); the identity verification unit compares the user verification information (two-dimensional code content, NFC data, face features) with the order information stored in the blockchain to verify the order validity (not refunded, not changed, within the valid period) and identity consistency; the result feedback unit returns "pass", "reject", "manual verification required" result to the verification terminal (airport boarding terminal, train gate, flight attendant handheld terminal), and synchronously updates the order state to "verified" and uploads it to the chain;

[0012] Data evidence module: store key data of the whole process of the ticket, including order data (generation, state change record), payment data (payment voucher, settlement record), verification data (verification time, place, method, result), user authorization data (information use authorization, authorized subscription). The module uses "hash on-chain + distributed storage" architecture, key data is written into the blockchain after SHA-256 hashing, and the original data is encrypted and stored in distributed nodes (node number ≥ 10, geographical distribution covers more than 3 regions), the storage validity period is consistent with the ticket validity period (after expiration, automatically archived to cold storage node, storage period ≥ 3 years); support authorized query of regulatory agencies (CAAC, RAILWAY BUREAU) to evidence data, query operation leaves traces and is on-chain, ensuring data traceability and tamper resistance;

[0013] The comprehensive supporting module and the blockchain order management module are connected through a TLS1.3 encrypted API interface, and only receive "paid" order desensitization data verified by 3 consensus nodes. Its included subsystem technology implementation is as follows:

[0014] Meal reservation system: based on trip period and user historical preference hash data, recommend meals with similarity ≥ 70% through rule engine, recommendation results include delivery time, record hash on-chain;

[0015] Tour reservation system: extract destination hash value from blockchain order, call encrypted interface of tourism platform, recommend daily / next day scenic spot tickets combined with arrival time, real-time passenger flow data synchronized on-chain every second;

[0016] Hotel reservation system: filter protocol hotels according to order time and predicted connection time consumption, protocol information is updated to distributed nodes every 24 hours through smart contract;

[0017] Convenient payment system: interface with government affairs platform, support 8 types of payment, record includes bill hash on-chain, hash account every hour;

[0018] Life e-commerce platform: recommend necessities based on trip type and duration, call inventory within 3 kilometers, logistics status on-chain every 10 minutes.

[0019] When the blockchain order management module generates "paid" state event, the comprehensive supporting module completes the recommendation within 500ms, and pushes the content including evidence identification through the client.

[0020] Further, it also includes an order risk assessment unit, which is linked with the blockchain order management module and the user interaction module, calculates the order risk value through multi-dimensional parameters, identifies abnormal orders and triggers targeted control to avoid order fraud and financial loss; the risk assessment formula is as follows: R = a x H + b x O + g x T

[0021] In the formula, R is the order risk value (dimensionless, range [0, 100], R≥70 is determined as high risk and needs secondary verification; R≤30 is determined as low risk and can be quickly passed), a is the user historical credit weight (dimensionless, value 0.4, user history without abnormal order a=0.4, 1 time abnormal a=0.3, 2 times and above a=0.2), H is the user historical credit score (dimensionless, range [0, 100], based on the order performance in the past 12 months, payment record calculation, no default H=100, each default 1 time deducts 20 points), β is the order abnormal coefficient weight (dimensionless, value 0.35), O is the order abnormal coefficient (dimensionless, range [0, 100], there is "different IP+very used equipment+instantaneous order" combination O=100, only single abnormal item O=30, no abnormal O=0), γ is the time sensitive weight (dimensionless, value 0.25), T is the time sensitive coefficient (dimensionless, range [0, 100], order within 24 hours before departure T=80, order within 24-72 hours T=40, order more than 72 hours T=10).

[0022] Further, it also includes a ticket change optimization unit, which is based on the non-tamperable and ownership traceability characteristics of the blockchain. The unit presets a ticket change rule library. When the user submits a change application, the system first checks whether it meets the rules: when the change application meets the rules, the user selects the target train / flight, date, and cabin / seat, and the system verifies the target ticket status in real time through the blockchain data synchronization unit; when the ticket is valid, the difference between the original ticket and the new ticket is automatically calculated, and the difference payment instruction is generated through the multi-modal payment module; after the user completes the difference payment, the system freezes the original ticket state to "has been changed" and chains, and integrates the new itinerary information to generate a unique new order number, which is written into the blockchain after processing; the new order state is updated to "has been changed-valid".

[0023] Further, it also includes a payment settlement optimization unit, which optimizes the cooperation of blockchain nodes and data transmission paths to improve the payment settlement delay of cross-subjects (users, platforms, airlines / railways, banks), and shorten the fund arrival period. The settlement delay optimization formula is as follows:

[0024] In the formula, E is the settlement delay condition (unit: yuan / second, the larger the value, the higher the efficiency), A is the total amount of single settlement (unit: yuan, that is, the total payment of a batch order), S is the node cooperation coefficient (dimensionless, range [0.6, 1.0], node synchronization rate ≥ 95% S = 1.0, and S decreases by 0.1 for every 5% decrease in synchronization rate), N is the number of nodes participating in settlement (unit: pieces, including user end nodes, platform nodes, airline / railway nodes, and bank nodes, and the default N = 4), and D is the average network delay (unit: seconds, obtained in real time through a blockchain network monitoring tool, and the target D ≤ 0.5 seconds).

[0025] The blockchain node cluster is connected with the blockchain order management module and is used to provide distributed consensus verification. The blockchain node cluster adopts ≥3 consensus nodes, the consensus response time is ≤1 second, and the on-chain delay is ≤2 seconds. The key data includes order data, payment vouchers, and risk assessment results. The cluster simultaneously provides consensus support for the state update of the blockchain order management module and provides underlying storage nodes for the "hash on-chain" of the data storage module.

[0026] Further, a user privacy protection unit is further included. The unit adopts a "zero-knowledge proof + data desensitization + permission control" three-level protection mechanism to prevent user privacy data leakage while ensuring normal business development. The zero-knowledge proof is applied to the identity verification scene: the first level of protection is that when verifying a ticket, the user does not need to submit complete privacy information such as the identity card number and mobile phone number to the verification terminal, but only needs to generate a zero-knowledge proof that the user is the owner of the order. The verification terminal verifies the validity of the proof through the blockchain without obtaining the original privacy data. The data desensitization processing is directed to the stored user information: the identity card number only retains the first and last two digits, and the middle is replaced with "*"; the mobile phone number retains the first three and last four digits. The second level of protection is that the original data is stored in an offline cold node using a homomorphic encryption algorithm and is decrypted only when the user initiates information modification. The third level of protection is based on system role-based access control: the system roles are divided into users, platform operators, regulatory authorities, and technical maintenance personnel. All permission change operations are logged and chained to ensure traceability. Through the three levels of protection, the risk of user privacy data leakage is reduced to below 0.01%.

[0027] Further, it also includes a system internal data synchronization unit, which realizes real-time synchronization of internal data of the system and solves the problems of traditional systems, such as inconsistent remaining tickets, out-of-sync order status, and delayed feedback of payment results. The unit adopts a “blockchain distributed ledger + incremental synchronization” mechanism: each functional node acts as a consensus node of the blockchain (the number of nodes ≥ 8), and real-time obtains order, remaining ticket, and payment data in the ledger; the synchronization content includes remaining ticket update, order status synchronization, and payment result synchronization; the synchronization conflict resolution adopts the principle of “timestamp priority + consensus verification”: if different platforms simultaneously update the same order status, the update request with the earlier timestamp is used as the reference, and if the timestamp difference ≤ 100 ms, the update request is submitted to the consensus node for voting (≥ 2 / 3 nodes pass, which is valid).

[0028] Further, it also includes an intelligent contract automatic performance unit, which presets performance rules for ticket refund and change scenarios, realizes full-automatic execution of service charge calculation, refund initiation, and order status update, and does not require manual intervention. The ticket refund service charge calculation formula is as follows:

[0029] In the formula, F is the ticket refund service charge (unit: yuan, with two decimal places), P is the original ticket price (unit: yuan, i.e. the face value amount in the order), K is the ticket type coefficient (dimensionless, full-price ticket K = 0.1, discount ticket with discount rate 80%-99% K = 0.2, discount ticket with discount rate 70%-79% K = 0.3, discount ticket with discount rate < 70% cannot be refunded, K is meaningless), T is the valid period of the ticket (unit: hours, the total duration from order generation to departure time, such as ordering 24 hours before departure, then T = 24), and t is the time duration from the ticket refund application time to the departure time (unit: hours, such as applying for a refund 12 hours before departure, then t = 12).

[0030] Further, it also includes a ticket traceability unit, which relies on the chain storage structure of the blockchain to realize the full-process traceability of the ticket from ordering, payment, verification to use completion (or refund / change), and provides the basis for dispute handling and regulatory audit. The traceability information includes key data at each step: ordering link (order generation time, user operation terminal IP, user information hash), payment link (payment time, payment method, payment amount, payment account hash), verification link (verification time, verification location, verification terminal number, verification personnel (if manual)), change link (change / refund time, change reason, handling fee / difference, new order number (if change)); the traceability query supports multi-dimensional search: users can query their own ticket traceability records by order number, regulatory agencies can search traceability data by time period, ticket type and operation subject, and judicial agencies can query the complete traceability information of a specific ticket according to judicial documents; the traceability accuracy reaches millisecond level (time stamp accurate to millisecond), location level (verification location accurate to airport terminal / boarding gate, train station platform / gate), and all traceability data are stored in the blockchain permanent node and cannot be tampered with or deleted. For example, if a user has a dispute over the refund handling fee, he / she can query the refund application time, ticket type and handling fee calculation process through the traceability unit, compare the contract rules, and if there is an anomaly (such as incorrect handling fee calculation), he / she can initiate a complaint based on the traceability record, and the platform can quickly verify and handle it based on the traceability data, with a complaint handling efficiency improved by more than 60%.

[0031] Further, it also includes a system load balancing unit, which dynamically allocates computing, storage and network resources by monitoring system resource occupation and user access in real time, to ensure stable operation of the system during peak periods (such as holiday ticket purchase peak, promotion activities) and avoid lag and crashes. Load monitoring indicators include: CPU usage (warning threshold ≥ 85%), memory occupation (warning threshold ≥ 80%), number of concurrent users (warning threshold ≥ 10,000), order processing volume (warning threshold ≥ 5,000 orders / minute), network bandwidth occupation (warning threshold ≥ 90%); resource adjustment strategy adopts "elastic expansion + node scheduling": when a certain indicator exceeds the warning threshold, the system automatically starts the standby server (CPU and memory resource expansion, expansion response time ≤ 30 seconds), and at the same time, some user requests are scheduled to nodes with lower load (such as southern users to South China node, northern users to North China node); the load balancing algorithm adopts a combination of "weighted round robin + minimum connection number": for ordinary query requests, weighted round robin is used (weight is allocated according to node load, lower load has higher weight), and for order generation, payment and other key requests, minimum connection number is used (allocated to the node with the least number of connections); through load balancing, the system still has a response delay of ≤ 2 seconds when the number of concurrent users reaches 20,000 and the order processing volume reaches 8,000 orders / minute, without service interruption, meeting the demand for peak period use.

[0032] Further, it also includes a multilingual and multi-currency adaptation unit, which supports cross-border user use and solves the problems of "language barrier and cumbersome currency conversion" of traditional systems. The multilingual adaptation supports 12 major languages (Chinese, English, Japanese, Korean, French, German, Spanish, Russian, Arabic, Portuguese, Indonesian, Vietnamese), and the interface language can be automatically switched according to the user terminal system language, and manual selection is also supported; the language content is translated by professional localization (such as the aviation term "cabin" corresponding to English "Cabin Class", the railway term "seat class" corresponding to English "Seat Class"), ensuring no ambiguity; the multi-currency adaptation supports 20 major legal currencies (RMB, US dollars, euros, pounds, Japanese yen, Korean won, etc.) and 5 compliant digital currencies (digital RMB, digital euro prototype in the euro area, etc.), and the currency conversion uses real-time exchange rate (the latest exchange rate is obtained from the central bank and the Bank for International Settlements every 5 minutes, and the exchange rate error is ≤0.01%); when paying, the user can choose the original currency (ticket pricing currency) or the target currency (user's commonly used currency), and the system automatically calculates and displays the converted amount (such as "1000 yuan ≈ 140 dollars").

[0033] Further, it also includes a distributed node health monitoring and self-healing unit, which is linked with the blockchain node cluster and the system load balancing unit, and monitors the running state of the consensus node and the data synchronization validity in real time; the monitoring indicators include: node CPU usage, memory occupancy, data synchronization rate, and consensus response delay;

[0034] When the indicators of a certain node trigger a warning, the unit automatically determines the fault type: if it is resource overload, the system load balancing unit is called to start the standby node, and the task migration of the failed node is completed within 10 seconds, and node switching logs are generated during the migration process; if it is a synchronization exception, the data retransmission mechanism is automatically triggered, and after the retransmission is completed, the data consistency is verified through block hash comparison;

[0035] After the fault handling is completed, the unit encrypts the fault information and node running logs with AES-256 and uploads them to the chain for storage, and at the same time pushes the node health report to the technical maintenance role terminal; in addition, the unit supports generating a node cluster health trend chart every day, and the chart data is written into the data storage module after being hashed, which is convenient for technical maintenance personnel to trace and optimize node configuration.

[0036] Further, it also includes a regulatory intelligent early warning unit, which is linked with the data storage module and the blockchain order management module, and builds a multi-dimensional regulatory analysis model based on real-time on-chain data of the blockchain; the analysis model includes: abnormal order cluster identification dimension, payment abnormal fluctuation dimension, and verification abnormal dimension;

[0037] When the data of a certain dimension triggers a preset threshold, the unit automatically generates a warning message and pushes it to the corresponding regulatory agency terminal through an encrypted channel; at the same time, the data storage module is called to generate a phased regulatory audit report, which is stored in real time after being generated; in addition, the unit supports the regulatory agency to customize the warning threshold and analysis dimension, and the customized rules are written into the smart contract after being verified by three consensus nodes, ensuring the flexibility and compliance of supervision.

[0038] Further, it also includes a special population service adaptation unit, which cooperates with the user interaction module and the ticket verification module to provide exclusive service functions for special groups such as elderly users and disabled users;

[0039] At the user interaction level: support voice interaction operation, large font interface, and simplified operation process;

[0040] At the ticket verification level: add iris recognition auxiliary verification and manual verification green channel triggering function;

[0041] At the service interface level: automatically associate special service reservations, after the user completes the order, the system pushes the reservation request to the special service department, and the feedback result is synchronized to the user terminal within 30 seconds and stored in the chain; all special population operation logs are separately classified and archived in the data storage module after desensitization, facilitating subsequent service optimization analysis.

[0042] Compared with the existing technology, the beneficial effects of the present application are:

[0043] The present application solves the problems of poor data security, low process efficiency and insufficient function adaptability of the existing system through the deep integration of blockchain technology and ticketing system, significantly improving the security, convenience and collaboration of aviation and railway electronic ticket booking and payment. In terms of data security and credibility, the distributed ledger and tamper-proof characteristics of blockchain ensure that order information, payment data and user privacy are not tampered with throughout the life cycle, the order chaining and verification accuracy are high, and the risk of data leakage and malicious attacks under the centralized architecture is effectively avoided; at the same time, the complete evidence chain is formed by chaining all the data in the whole process, when there is a ticket dispute, the user and the regulatory department can directly trace the data source, greatly reducing the cost of rights protection and supervision, solving the problem of lack of traditional system storage and difficult dispute resolution.

[0044] In terms of process efficiency and automation, the introduction of smart contract realizes the automatic execution of booking, payment, refund and change, without human intervention, significantly shortening the order processing and fund settlement cycle; the multi-modal payment module supports dual-track payment of legal currency and digital currency, adapts to the payment habits of different users, has high payment success rate and fast arrival speed; the data synchronization unit in the system avoids the problem of booking failure caused by inconsistent data, improves the user operation experience, and solves the problem of poor collaboration and process lag in traditional system platform.

[0045] In terms of function adaptation and user experience, the system integrates meal reservation, hotel accommodation, and convenient payment and other comprehensive supporting services, realizes "one-stop" travel service, and does not require users to switch multiple platform operations; the multi-language and multi-currency adaptation unit supports cross-border users, eliminates language barriers and currency conversion problems, and widens the system application range; the user privacy protection unit protects user privacy to the maximum extent through multi-level encryption and permission control while ensuring normal business development, and meets data security regulation requirements. Overall, the present application promotes the transformation of the aviation and railway electronic ticket system from "centralization and single function" to "decentralization and full-scene cooperation", which not only meets the needs of users for safe and efficient travel, but also adapts to the requirements of multi-subject cooperation and supervision, and has significant practical value and industry promotion significance. BRIEF DESCRIPTION OF DRAWINGS

[0046] Figure 1 A schematic block diagram of an electronic ticket ordering and payment application system based on a blockchain is provided for the present application.

[0047] Figure 2 A comparison chart of the core performance of the traditional ticketing system and the ticketing system based on the blockchain is provided.

[0048] Figure 3 A comparison chart of the order status flow efficiency of the ticketing system is provided.

[0049] Figure 4 A comparison chart of the payment method and security adaptation of the ticketing system is provided. DETAILED DESCRIPTION

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

[0051] In the description of the present application, it should be understood that the terms "center", "longitudinal", "transverse", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", "counterclockwise" and the like indicate the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the devices or elements referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as a limitation of the present application.

[0052] Furthermore, the terms "first", "second", etc. are used only for descriptive purposes and are not to be construed as indicating or implying relative importance or a specific number of features indicated. Therefore, the features defined with "first", "second" can explicitly or implicitly include one or more of the features. In the description of the present application, the meaning of "a plurality of" is two or more, unless otherwise specifically limited. In addition, the terms "mounting", "connecting", "connecting" should be broadly understood, for example, it can be fixedly connected, or it can be detachably connected, or integrally connected; it can be mechanically connected, or it can be electrically connected; it can be directly connected, or it can be indirectly connected through an intermediate medium, or it can be the communication inside two elements. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances, and the present application will be further described in detail below with reference to the drawings.

[0053] Referring to Figures 1 to 4 An electronic ticket ordering and payment application system based on a blockchain includes the following modules:

[0054] User interaction module: provides multi-terminal operation entry for users, supports mobile phone APP (iOS / Android system, version ≥10.0 / 12.0), PC terminal (browser compatible Chrome ≥90.0, Edge ≥88.0), and smart terminal access. The module supports ticket query (filtering by trip, date, cabin / seat type, query result loading time ≤0.8 seconds), ordering (automatically filling user information after selecting a ticket, supporting batch ordering of 1-10 people), changing (changing date / train / flight, real-time display of remaining tickets and price difference), and refund (triggering smart contract pre-check after submitting application) operations; built-in user information management unit, storing desensitized user information (name, certificate number hash value, contact information encrypted storage), supporting information modification and authorization management (such as authorizing others to order on behalf of), and operation log real-time synchronization to the blockchain storage module;

[0055] Blockchain order management module: responsible for the whole life cycle data of the order on the chain and management, including order generation unit, state update unit, query unit; order generation unit receives the subscription request of user interaction module, integrates itinerary information (departure / destination, date, time, cabin / seat), user information, payment information, generates a unique order number (uses UUID+block height of blockchain combined coding), and writes into the blockchain after processing by SHA-256 hash algorithm; the state update unit updates the order state in real time according to the ticket use process (to be paid→paid→to be verified→verified→completed / refunded / changed), and the state change needs to be verified by at least 3 consensus nodes; the query unit supports users to query orders by order number, certificate number hash value, mobile phone encrypted value, and the query result includes complete state flow record and corresponding block hash, and the query response time is ≤1 second; when the state changes to "paid", send service trigger instruction to the comprehensive supporting system;

[0056] Multi-modal payment module: supports dual-track payment of legal currency and digital currency, including payment method selection unit, encrypted transmission unit, payment verification unit. Legal currency payment supports bank cards (UnionPay, Visa, MasterCard, using EMV chip encryption standard), third-party payment (Alipay, WeChat payment, connecting official API, payment interface encryption level ≥ TLS1.3); digital currency payment supports mainstream compliant digital currency (such as digital RMB, connecting the interface of the central bank digital currency research institute), using offline payment and online synchronization combination mode; the encrypted transmission unit uses AES-256 encryption for payment instructions (amount, account information, order number), and payment data is only visible to payment parties and necessary consensus nodes; the payment verification unit receives the payment result feedback from the payment center, generates a payment voucher and uploads it to the chain, and the payment response time is ≤3 seconds, and when the payment fails, it automatically triggers the refund pre-application and notifies the user;

[0057] Ticket verification module: realizes multi-scene quick verification of tickets, including verification method adaptation unit, identity verification unit, and result feedback unit. Verification methods support dynamic QR code (updated every minute, using QRCode format, containing order hash and time limit parameter), NFC near field communication (supports mobile phone NFC, physical card simulation, verification distance ≤5cm), face recognition (connects to the public security face database, recognition speed ≤0.5 seconds, accuracy ≥99.8%); the identity verification unit compares the user verification information (two-dimensional code content, NFC data, face features) with the order information stored in the blockchain to verify the order validity (not refunded, not changed, within the valid period) and identity consistency; the result feedback unit returns "pass", "reject", "manual verification required" result to the verification terminal (airport boarding terminal, train gate, flight attendant handheld terminal), and synchronously updates the order state to "verified" and uploads it to the chain;

[0058] Data storage module: store key data of the whole process of the ticket, including order data (generation, state change record), payment data (payment voucher, settlement record), verification data (verification time, place, method, result), user authorization data (information use authorization, authorized booking). The module adopts "hash on-chain + distributed storage" architecture, key data is written into the blockchain after SHA-256 hashing, and the original data is encrypted and stored in distributed nodes (node number ≥ 10, geographical distribution covers more than 3 regions), the storage validity period is consistent with the ticket validity period (after expiration, automatically archived to cold storage node, storage period ≥ 3 years); support authorized query of supervision agencies (CAAC, railway bureau) to store data, query operation leaves traces and is on-chain, ensuring data traceability and tamper resistance;

[0059] Smart contract scheduling module: pre-deploy multiple types of smart contracts and realize automatic triggering and execution, including ordering contract (trigger condition: user submits ordering request and completes payment, execution action: generate electronic ticket, update order status), refund contract (trigger condition: user submits refund application and meets refund rules, execution action: calculate service charge, initiate refund, update order status), change contract (trigger condition: user submits change application and has remaining tickets, execution action: calculate price difference, update itinerary information, regenerate ticket), settlement contract (trigger condition: ticket use is completed / validity period ends, execution action: distribute settlement funds to airline / railway department, platform party). The contract code is audited by a third party, the execution delay is ≤2 seconds, and the execution result is automatically stored on-chain;

[0060] The comprehensive supporting module is connected with the blockchain order management module through the TLS1.3 encrypted API interface, and only receives desensitized itinerary data of "paid" state orders verified by 3 consensus nodes (including departure / arrival time, destination, itinerary duration hash value), which contains the meal reservation system, tourism reservation system, hotel reservation system, convenient payment system, and life e-commerce platform based on blockchain technology to realize intelligent service:

[0061] The meal reservation system combines the itinerary period of the blockchain order (such as ≥2 hours of travel to preferentially recommend hot food) and the user's historical preference hash data in the public storage system, and recommends meals with a similarity of ≥70% through a rule engine, the recommendation result includes the delivery time based on the itinerary calculation (error ≤10 minutes), and the record is hashed on-chain;

[0062] The tourism reservation system extracts the destination hash value from the blockchain order, calls the destination travel platform encryption interface through the data synchronization unit, recommends the same day / next day scene ticket based on the arrival time, and synchronizes real-time passenger flow data on-chain every second;

[0063] The hotel reservation system filters the agreement hotel according to the order departure / arrival time and superimposes the traffic connection time consumption prediction model (error ≤15 minutes), and the agreement hotel information is automatically updated to the distributed node (≥5) every 24 hours through the smart contract;

[0064] The convenient payment system follows the interface specification of the national integrated government service platform, adopts the national SM4 algorithm to connect the government platform, supports 8 types of payment, and the payment record contains the bill number hash and is updated on the chain in real time, and is reconciled with the government platform hash every hour;

[0065] The life e-commerce platform recommends travel necessities based on the order travel type and duration of the blockchain, calls the inventory information of the distribution point within 3 kilometers, and updates the logistics status every 10 minutes on the chain.

[0066] When the blockchain order management module generates a "paid" state event (including order number and travel information hash) through the preset smart contract and is verified by the consensus node, the comprehensive supporting module subsystems complete the recommendation calculation within 500ms, and after the information processing server integrates and removes the duplicate, the recommended content containing the blockchain storage identification is sent according to the user client push preference, all data interaction adopts AES-256 encryption, user privacy data participates in the calculation with the hash value, and the original data is stored in the offline cold node through homomorphic encryption.

[0067] In the application, the order risk assessment unit is also included, which is linked with the blockchain order management module and the user interaction module, calculates the order risk value through multi-dimensional parameters, identifies abnormal orders and triggers targeted control, avoids order fraud and fund loss; the risk assessment formula is as follows: R=α×H+β×O+γ×T

[0068] In the formula, R is an order risk value (dimensionless, range [0, 100], R>=70 is determined as high risk and needs secondary verification; R<=30 is determined as low risk and can be quickly passed), alpha is a user historical credit weight (dimensionless, value 0.4, user history without abnormal order alpha=0.4, 1 time of abnormality alpha=0.3, 2 times and above alpha=0.2), H is a user historical credit score (dimensionless, range [0, 100], calculated based on order performance in the past 12 months and payment records, no default H=100, each default 1 time deducts 20 points), beta is an order abnormality coefficient weight (dimensionless, value 0.35), O is an order abnormality coefficient (dimensionless, range [0, 100], exists 'abnormal IP + very used equipment + instantaneous order' combination O=100, only a single abnormal item O=30, no abnormality O=0), gamma is a time sensitivity weight (dimensionless, value 0.25), and T is a time sensitivity coefficient (dimensionless, range [0, 100], orders within 24 hours before departure T=80, orders within 24-72 hours T=40, orders more than 72 hours T=10); for example, a user historical credit score H=90 (no default), order no abnormality (O=0), order within 48 hours before departure (T=80), then R=0.4*90+0.35*0+0.25*40=36+0+10=46 (low risk), and the order is quickly passed; if the user historical credit score H=60 (1 time of default), the order contains 'abnormal IP + very used equipment' (O=80), and the order is within 12 hours before departure (T=80), then R=0.3*60+0.35*80+0.25*80=18+28+20=66 (medium risk), the system triggers a short message verification code secondary verification, and after verification, the payment can continue.

[0069] In the application, a ticket change optimization unit is further included, the unit presets a ticket change rule library, when a user submits a change application, the system first verifies whether the change application conforms to the rules: when the change application conforms to the rules, the user selects a target train / flight, date and cabin / seat, the system verifies the target ticket status in real time through the blockchain data synchronization unit; when the ticket is valid, the difference between the original ticket and the new ticket is automatically calculated, and a difference payment instruction is generated through a multi-modal payment module; after the user completes the difference payment, the system freezes the original ticket state to 'has been changed' and chains, and integrates new travel information to generate a unique new order number, which is written into the blockchain after processing; the new order state is updated to 'has been changed-valid'.

[0070] The change rule library includes: change time limit, change times, cabin / seat change restriction; if the user changes to a train / flight without tickets on the same day, the system automatically recommends similar trips within 72 hours and marks the ticket dynamic.

[0071] In the present application, a payment settlement optimization unit is also included, which optimizes the blockchain node cooperation and data transmission path, improves the payment settlement delay across subjects (users, platforms, airlines / railways, banks), and shortens the fund arrival period. The settlement delay optimization formula is as follows:

[0072] In the formula, E is the settlement delay (unit: yuan / second, the larger the value, the higher the efficiency), A is the total amount of a single settlement (unit: yuan, i.e. the total payment of a batch of orders), S is the node cooperation coefficient (dimensionless, range [0.6, 1.0], node synchronization rate ≥ 95% S = 1.0, synchronization rate decreases by 5% S decreases by 0.1), N is the number of nodes participating in settlement (unit: pieces, including user end nodes, platform nodes, airline / railway nodes, and bank nodes, default N = 4), D is the average network delay (unit: seconds, real-time acquisition through blockchain network monitoring tools, target D ≤ 0.5 seconds). For example, a batch settlement amount A = 100000 yuan, node cooperation coefficient S = 0.9 (node synchronization rate 92%), participating nodes N = 4, network delay D = 0.4 seconds, then E = (100000 x 0.9) / (4 x 0.4) = 90000 / 1.6 = 56250 yuan / second, settlement time ≈ 1.78 seconds; if the network delay rises to D = 0.8 seconds, the system automatically selects standby nodes with delay ≤ 0.5 seconds (N remains 4), S remains 0.9, then E = (100000 x 0.9) / (4 x 0.5) = 90000 / 2 = 45000 yuan / second, still ensuring settlement time ≤ 2.2 seconds. The unit also supports "batch settlement" mode (orders are aggregated by hour / day), further reducing node interaction frequency, shortening the airline / railway fund arrival period from T+1 to T+0.5 (i.e. arrival within 12 hours after settlement).

[0073] The blockchain node cluster establishes encrypted communication connections with the information processing server, the public storage system, and the payment center server, providing real-time on-chain storage and distributed consensus verification for key data in the system; the blockchain node cluster uses ≥ 3 consensus nodes, with a consensus response time ≤ 1 second and an on-chain delay ≤ 2 seconds; the key data includes order data, payment vouchers, and risk assessment results, and the cluster also provides consensus support for state updates of the blockchain order management module and underlying storage nodes for "hash on-chain" of the data evidence module.

[0074] In the present application, a user privacy protection unit is also included, which adopts a three-level protection mechanism of "zero-knowledge proof + data desensitization + authority control" to prevent user privacy data leakage while ensuring normal business development. Zero-knowledge proof is applied to identity verification scenarios: the first level of protection is that when verifying tickets, users do not need to submit complete certificate numbers, mobile phone numbers and other private information to the verification terminal, but only need to generate a zero-knowledge proof of "proving oneself as the owner of the order" (including order hash and identity feature hash association verification), and the verification terminal verifies the validity of the proof through the blockchain without obtaining the original private data; data desensitization processing is applied to stored user information: certificate numbers only retain the first and last two digits, and the middle is replaced with "*" (such as 1101********1234), and mobile phone numbers retain the first three and last four digits (such as 138***5678), the second level of protection is that the original data is stored in an offline cold node using a homomorphic encryption algorithm and is decrypted only when the user initiates information modification; the third level of protection is that the authority control adopts role-based access control (RBAC): system roles are divided into users (only access own orders and information), platform operators (access order statistical data without private fields), regulatory agencies (authorized to access specific range data according to regulatory needs), and technical maintenance personnel (only maintain the system without data access rights), all permission change operations are logged and chained to ensure traceability. Through the three levels of protection, the risk of user privacy data leakage is reduced to less than 0.01%.

[0075] In the present application, a system internal data synchronization unit is also included, which realizes real-time synchronization of the system and internal data, and solves the problems of "inconsistent remaining tickets, out-of-sync order status, and delayed payment result feedback" in the traditional multi-platform mode. The unit adopts a "blockchain distributed ledger + incremental synchronization" mechanism: each functional node is a consensus node of the blockchain (the number of nodes is greater than or equal to 8), and real-time order, remaining ticket, and payment data in the ledger are obtained; the synchronization content includes remaining ticket update (remaining ticket changes are pushed every 30 seconds, and the system updates the remaining ticket pool in the blockchain), order status synchronization (users initiate changes to orders or tickets, and the status changes are real-time chained), and payment result synchronization (payment credentials are chained after payment is completed, and the system can query and verify to avoid duplicate payments); the synchronization conflict resolution adopts the principle of "timestamp priority + consensus verification": if different functional nodes in the system update the same order status at the same time, the update request with the earlier timestamp is used as the reference, and if the timestamp difference is less than or equal to 100 ms, the request is submitted to the consensus node for voting (more than 2 / 3 nodes pass to be valid).

[0076] In the present application, the smart contract automatic performance unit is also included, which presets performance rules for ticket refund and change scenarios, realizes full-automatic execution of service charge calculation, refund initiation and order state update without manual intervention. When a user submits a ticket refund application, the smart contract automatic performance unit verifies whether the ticket refund rules are met. When the smart contract automatic performance unit determines that the ticket refund rules are met, the service charge and refund amount are calculated, the smart contract automatic performance unit initiates the refund to the user's payment account according to the refund amount, updates the order state to be refunded and chains, and pushes the ticket refund success and refund notice to the user after the ticket refund order is chained.

[0077] In the present application, the ticket traceability unit is also included, which relies on the chain storage structure of the blockchain to realize the full-process traceability of the ticket from ordering, payment, verification to use completion (or refund / change), and provides the basis for dispute handling and supervision audit. The traceability information includes the key data of each step: ordering link (order generation time, user operation terminal IP, user information hash), payment link (payment time, payment method, payment amount, payment account hash), verification link (verification time, verification location, verification terminal number, verification personnel (if manual)), change link (change / refund time, change reason, service charge / difference, new order number (if change)); the traceability query supports multi-dimensional search: the user can query his / her ticket traceability record by order number, the supervisory agency can search the traceability data according to time period, ticket type and operation subject, and the judicial agency can query the complete traceability information of a specific ticket according to judicial documents; the traceability accuracy reaches millisecond level (time stamp accurate to millisecond), location level (verification location accurate to airport terminal / boarding gate, train station platform / gate), and all traceability data are stored in the blockchain permanent node and cannot be tampered with or deleted. For example, a user may have a dispute over the ticket refund service charge, and can query the ticket refund application time, ticket type and service charge calculation process through the traceability unit, compare the contract rules, and if there is an exception (such as incorrect service charge calculation), the user can initiate a complaint according to the traceability record, and the platform can quickly verify and handle the complaint according to the traceability data, and the complaint handling efficiency is improved by more than 60%.

[0078] In the present application, a system load balancing unit is also included, which dynamically allocates computing, storage and network resources by monitoring system resource occupation and user access in real time, to ensure stable operation of the system during peak periods (such as holiday ticket purchase peak, promotion activities), and to avoid freezing and crashes. Load monitoring indicators include: CPU usage (warning threshold ≥ 85%), memory occupation rate (warning threshold ≥ 80%), number of concurrent users (warning threshold ≥ 10,000 people), order processing volume (warning threshold ≥ 5,000 orders / minute), network bandwidth occupation rate (warning threshold ≥ 90%); resource adjustment strategy is "elastic expansion + node scheduling": when a certain indicator exceeds the warning threshold, the system load balancing unit automatically starts the standby server (CPU and memory resource expansion, expansion response time ≤ 30 seconds), and at the same time, part of the user requests are scheduled to the nodes with lower load (such as scheduling southern users to the South China node and northern users to the North China node); the load balancing algorithm uses a combination of "weighted round robin + minimum connection number": for ordinary query requests, weighted round robin is used (assign weights according to node load, lower load with higher weight), and for order generation, payment and other key requests, minimum connection number is used (assigned to the node with the least current connection number); through load balancing, when the number of concurrent users reaches 20,000 and the order processing volume reaches 8,000 orders / minute, the response delay is still ≤ 2 seconds, there is no service interruption, and the demand for peak period use is met.

[0079] In the application, a multi-language and multi-currency adaptation unit is also included, which supports cross-border user use and solves the problems of "language barrier and cumbersome currency conversion" of traditional systems. The multi-language adaptation supports 12 main languages (Chinese, English, Japanese, Korean, French, German, Spanish, Russian, Arabic, Portuguese, Indonesian, Vietnamese), and the interface language can be automatically switched according to the user terminal system language, and manual selection is also supported. The language content is translated by professional localization (such as the aviation term "cabin" corresponding to English "Cabin Class" and the railway term "seat class" corresponding to English "Seat Class"), which ensures no ambiguity. The multi-currency adaptation supports 20 main legal currencies (Renminbi, US dollar, euro, British pound, Japanese yen, Korean won, etc.) and 5 compliant digital currencies (digital Renminbi, digital euro prototype in the euro area, etc.), and the currency conversion uses real-time exchange rate (the latest exchange rate is obtained from the central bank and the Bank for International Settlements every 5 minutes, and the exchange rate error is less than or equal to 0.01%). When paying, the user can select the original currency (ticket pricing currency) or the target currency (user's commonly used currency), and the system automatically calculates and displays the converted amount (such as "1000 yuan ≈ 140 dollars"). After payment, the settlement amount is converted into the settlement currency of the airline / railway according to the daily average price. For example, an overseas user uses an English interface to order a domestic high-speed rail ticket in China and selects to pay in US dollars. The system displays the amount of US dollars corresponding to 1000 yuan (according to the daily exchange rate), and after payment, the system converts the amount into Renminbi according to the daily average price and settles it to the railway department. The cross-border payment experience is consistent with that in China.

[0080] In the application, a distributed node health monitoring and self-healing unit is also included, which is linked with the blockchain node cluster and the system load balancing unit, and can monitor the running state of the consensus node and the data synchronization validity in real time. The monitoring indicators include: node CPU usage (warning threshold ≥ 90%), memory occupancy rate (warning threshold ≥ 85%), data synchronization rate (warning threshold ≤ 90%), and consensus response delay (warning threshold ≥ 2 seconds).

[0081] When the indicators of a certain node trigger a warning, the unit automatically determines the fault type (resource overload / synchronization anomaly): if it is resource overload, the system load balancing unit is called to start a standby node (select a node with a load of less than or equal to 60% from the standby pool of the node cluster), and the task migration of the faulty node is completed within 10 seconds. Node switching logs are generated during the migration process (including the fault node ID, standby node ID, and migration data volume). If it is a synchronization anomaly, the data retransmission mechanism is automatically triggered (missing data is obtained from three normal consensus nodes, and incremental synchronization is used for retransmission), and data consistency is verified after retransmission (by comparing block hashes).

[0082] After the fault handling is completed, the unit will store the fault information (fault type, handling time, result) and the node operation log (near 1 hour monitoring data) in the chain after AES-256 encryption, and push the node health report (including node state statistics, fault handling analysis) to the terminal of the technical maintenance role at the same time; in addition, the unit supports generating a node cluster health trend chart by day, and the chart data is written into the data storage module after hash processing, which is convenient for technical maintenance personnel to trace and optimize node configuration.

[0083] In the present application, a supervision intelligent early warning unit is also included, which is linked with the data storage module and the blockchain order management module, and a multi-dimensional supervision analysis model is constructed based on real-time on-chain data of the blockchain; the analysis model includes:

[0084] Abnormal order cluster identification dimension (the same IP / device generates more than 5 different user tickets within 1 hour);

[0085] Payment abnormal fluctuation dimension (single batch settlement amount deviates from historical same period mean value by more than 30%);

[0086] Verification abnormal dimension (the same ticket initiates verification more than 2 times at different locations and the interval is less than 1 hour);

[0087] When the data of a certain dimension triggers the preset threshold, the unit automatically generates early warning information (including abnormal data hash, associated order number) and pushes it to the terminal of the corresponding supervision agency (civil aviation bureau / railway bureau) through an encrypted channel; at the same time, the data storage module is called to generate a phased supervision audit report (including abnormal data statistics, trend analysis, and disposal suggestions), which is stored in the chain in real time after being generated; in addition, the unit supports the supervision agency to customize the early warning threshold and analysis dimension, and the customized rules are written into the smart contract after being verified by 3 consensus nodes to take effect, ensuring the flexibility and compliance of supervision.

[0088] In the present application, a special population service adaptation unit is also included, which cooperates with the user interaction module and the ticket verification module to provide exclusive service functions for special groups such as elderly users and disabled users;

[0089] At the user interaction level: support voice interaction operation (integrate dialect recognition model, cover at least 5 main dialects, voice command recognition accuracy ≥98%), large font interface (font size can be adjusted to 200% of the regular interface), simplified operation process (simplify the "query-order-payment" steps from the regular 5 steps to 3 steps);

[0090] At the ticket verification level: add iris recognition auxiliary verification (interface with public security iris database, verification response time ≤1 second), manual verification green channel triggering function (after the user submits a special demand application, the system automatically pushes the reservation information to the airport / station manual verification point, and the verification point obtains the user order hash 5 minutes in advance);

[0091] At the service interface level: automatically associate special service reservations (such as wheelchair service, priority boarding / riding), after the user completes the subscription, the system pushes the reservation request to the special service department, and the feedback result (reservation success / failure and reason) is synchronized to the user terminal within 30 seconds and is stored in the chain; All special population operation logs are desensitized and separately classified and archived in the data storage module for subsequent service optimization analysis.

[0092] Embodiment 1

[0093] Domestic railway electronic ticket booking and payment (daily commuting scenario)

[0094] I. System deployment and module configuration

[0095] This embodiment focuses on the domestic high-speed rail daily commuting scenario, integrates blockchain technology and the whole process service, and the architecture of "information processing server as the core, multi-terminal cooperation, and public storage system support" is as follows:

[0096] Core server and client

[0097] Information processing server: as the central system, connecting the client, payment center server, comprehensive supporting system, electronic ticket reservation system, responsible for command distribution and data interaction.

[0098] Client: support mobile terminal, PC terminal, smart terminal device, meet different user operation habits.

[0099] Payment center server: connect bank settlement system (UnionPay, WeChat payment interface) and digital currency transaction system (digital RMB wallet interface), support dual-track payment of legal currency and digital currency.

[0100] Public storage system

[0101] It includes data receiving unit (receives order, payment, and verification data from information processing server), data processing unit (SHA-256 hash processing after desensitizing original data), and data storage unit (distributed node storage, node ≥ 10, covering North China, East China, and South China regions).

[0102] The storage data includes order number, payment voucher, and user information hash, with a validity period consistent with the ticket (30 days), and after expiration, it is archived to cold storage (saved for ≥3 years).

[0103] Comprehensive supporting system

[0104] Meal reservation system: recommend high-speed rail meals based on travel duration (such as travel for more than 2 hours), support online booking and seat delivery.

[0105] Hotel booking system: Recommend high-speed rail station surrounding agreement hotels according to the arrival city (such as Shanghai), show the latest check-in time.

[0106] Convenient payment system: Interface with local government platforms, support users to pay for water and electricity fees after booking tickets.

[0107] Life e-commerce platform: Recommend travel necessities (such as power banks, umbrellas), support station self-pickup.

[0108] Blockchain and security module

[0109] Blockchain order management module: Deploy 8 consensus nodes (distributed in Beijing, Jinan, Shanghai Railway Bureau), use PBFT consensus mechanism, order generation and status update need ≥3 nodes verification.

[0110] Ticket verification module: Support dynamic two-dimensional code (updated every minute), NFC near field communication (verification distance ≤5cm), face recognition (accuracy ≥99.8%).

[0111] II. Complete business process implementation

[0112] Ticket inquiry and booking

[0113] Users query "Beijing South-Shanghai Hongqiao" G101 train (March 1, 8:00, second class seat) through mobile terminal, 0.7 seconds to load the remaining ticket information (35 tickets), the system calls the distributed remaining ticket pool data of the public storage system.

[0114] Select 2 people to order in batches, automatically fill in the desensitized user information (name + last 4 digits of ID card, such as "Li Si ****5678"), after submitting the order, the blockchain order management module generates the order number "UUID-52108" (UUID + block height) within 1 second, and hashes it to the chain.

[0115] Multi-mode payment

[0116] The payment center server receives the instruction, the user selects one person to pay by WeChat (380 yuan, through the bank settlement system) and one person to pay by digital RMB (380 yuan, through the digital currency transaction system).

[0117] The payment instruction is transmitted by AES-256 encryption, the WeChat payment response is 2.2 seconds, the digital RMB payment response is 1.5 seconds, and the payment voucher is generated and chained within 2 seconds.

[0118] After payment, the information processing server sends a "paid" instruction to the integrated support system, triggering service recommendations. The support service and the convenient payment and meal reservation system recommend the "high-speed lunch + mineral water" package, with a delivery time of "expected 9:30 to car 12". The hotel reservation system recommends a hotel near Shanghai Hongqiao Station ("10-minute walk, including breakfast").

[0119] The user pays the March electricity bill (amount 150 yuan) through the convenient payment system in the APP, and the payment record hash is written into the public storage system in real time. After 1 hour, the hash is reconciled with the government platform.

[0120] Station verification and trip completion

[0121] The user arrives at Beijing South Railway Station and generates a dynamic two-dimensional code by swiping his ID card at the intelligent terminal. The ticket verification module compares the blockchain order information (status "paid", identity consistent), and the verification is passed in 0.5 seconds. The gate is released, and the order status is updated to "verified" and linked to the chain.

[0122] Refund processing

[0123] Due to itinerary changes, the user applies for a refund for one person (second-class seat, full-price ticket) 24 hours before departure. The smart contract automatically executes the unit according to the formula to calculate the service charge: Yuan, and the refund amount is 361 yuan.

[0124] The refund is completed within 3 minutes (returned via WeChat Pay, and the funds are credited within 10 minutes), the order status is updated to "refunded" and linked to the chain, and the public storage system synchronously records the change data.

[0125] III. Key formula application order risk assessment

[0126] The user's historical credit score H = 90 (no default, α = 0.4), the order is normal (O = 0, β = 0.35), and the order is placed 72 hours before departure (T = 10, γ = 0.25). Therefore: R = 0.4 x 90 + 0.35 x 0 + 0.25 x 10 = 36 + 0 + 2.5 = 38.5 (low risk), and the order is quickly passed.

[0127] Daily settlement amount A = 5 million yuan, node cooperation coefficient S = 0.9 (synchronization rate 92%), participating nodes N = 4 (user side, railway, WeChat, and digital RMB nodes), network delay D = 0.3 seconds, then: Yuan / second, settlement time ≈ 1.33 seconds, and the fund crediting period is shortened from T+1 to T+0.5 (credited before 12:00 on the same day).

[0128] IV. Performance verification table

[0129]

[0130] This embodiment realizes the integration of ticket booking, multi-channel payment, secure storage, and convenient services in the domestic railway scenario through the "server-client-public storage" architecture. It highlights the characteristics of "people's livelihood service integration" and "multi-terminal collaboration", significantly improving user experience and system security.

[0131] Embodiment 2

[0132] Domestic Air Electronic Ticket Booking and Payment (Spring Festival Peak Scenario)

[0133] I. System deployment and module configuration

[0134] User interaction module: Use the official APP of the airline (iOS 16.0 / Android 13.0 version), the interface supports "trip query-ticket booking-ticket change and refund" one-stop operation. The query function is filtered by "departure city (such as Beijing)-destination city (such as Guangzhou)-date (January 25, 2025)-cabin (economy class)", calls the blockchain ticket pool data, and the loading time is 0.6 seconds; the booking function supports 5-person batch ordering, automatically fills in the desensitized user information (name+last 4 digits of ID number, such as "Zhang San ****1234"), and displays the number of remaining tickets (such as "23 economy class tickets") in real time next to the submit order button; the change function is linked with the airline flight system, and when the date is changed, the remaining tickets for the next 3 days are displayed synchronously (such as "18 tickets on January 26, difference +200 yuan"), and the operation log is synchronized to the blockchain storage module every 100ms.

[0135] Blockchain order management module: uses PBFT consensus mechanism, deploys 12 consensus nodes (distributed in Beijing, Guangzhou, Shanghai, and Chengdu, 3 nodes in each region), and the block generation interval is 2.5 seconds. After receiving the user booking request, the order generation unit integrates the trip information (Beijing Capital International Airport-Guangzhou Baiyun International Airport, January 25, 2025 08:30, economy class), user information (3 people, ID number hash value processed by SHA-256), and payment information (amount 1800 yuan / person), generates order number "UUID-68923" (UUID is the user device identifier, 68923 is the current blockchain block height), and writes it into the block after hashing; the state update unit updates the order status from "to be paid" to "paid" within 1 second after the user completes the payment, which needs to be verified by 6 nodes; the query unit supports user query by order number or encrypted mobile phone number (mobile phone number is encrypted by AES-256), the result contains "to be paid (08:00)→paid (08:01)→to be verified (08:25)→verified (08:30)" complete state chain, and the query response is 0.8 seconds.

[0136] Multi-modal payment module: Legal currency payment interface with UnionPay (EMV chip encryption), Alipay (TLS1.3 encryption interface), digital currency payment interface with Digital RMB APP (offline payment limit 2000 yuan). User selects 2 people to pay with Alipay (3600 yuan) and 1 person to pay with digital RMB (1800 yuan). Payment instructions are transmitted after AES-256 encryption. Alipay payment response is 2.5 seconds, and digital RMB payment response is 1.8 seconds. After receiving the feedback from the payment center, the payment verification unit generates payment vouchers (including payment time, amount, and account hash), which are uploaded to the chain within 2 seconds. When 1 person fails to pay (insufficient balance), the system automatically triggers a refund pre-application, and sends a short message to the user: "Order UUID-68923: 1 person failed to pay. Your remaining ticket has been reserved for 30 minutes. Please make up the payment."

[0137] Key formula application:

[0138] Order risk assessment: A user's historical credit score H = 95 (no default, α = 0.4), order is normal (O = 0, β = 0.35), order is placed 72 hours before departure (T = 10, γ = 0.25), then R = 0.4 × 95 + 0.35 × 0 + 0.25 × 10 = 38 + 0 + 2.5 = 40.5 (low risk), order is quickly passed; another user's historical credit score H = 60 (1 default, α = 0.3), order contains "different IP (Beijing IP order, commonly used IP is Shanghai) + unusual device" (O = 80, β = 0.35), order is placed 20 hours before departure (T = 80, γ = 0.25), then R = 0.3 × 60 + 0.35 × 80 + 0.25 × 80 = 18 + 28 + 20 = 66 (medium risk), trigger SMS verification for secondary verification, and continue payment after verification.

[0139] Settlement delay optimization: Spring Festival single-day settlement amount A = 180 million yuan, node cooperation coefficient S = 0.95 (12 nodes with 94% synchronization rate), participating nodes N = 4 (user side, airline, Alipay, and UnionPay), network delay D = 0.4 seconds, then E = (1.8 × 10 8 × 0.95) / (4 × 0.4) = 1.71 × 10 8 / 1.6 = 1.06875 × 10 8 yuan / second, settlement time ≈ 1.68 seconds, airline fund arrival period is shortened from traditional T+1 to T+0.5 (arrival before 18:00 on the same day).

[0140] II. Complete business process implementation

[0141] Ticket booking and blockchain entry: When a user opens the app and searches for economy class tickets from Beijing to Guangzhou on January 25, 23 remaining tickets are loaded in 0.6 seconds. The user selects 3 people to place an order, and the user information is automatically filled in. After the order is submitted, the blockchain order management module generates an order number and uploads it to the blockchain within 1 second. The user's terminal displays "Order created, pending payment".

[0142] Payment and Verification: Users select two Alipay accounts and one digital RMB payment. The payment instructions are transmitted in encrypted form. The Alipay payment is completed after 2.5 seconds, and the digital RMB payment is completed after 1.8 seconds. The payment voucher is uploaded to the blockchain, the order status is updated to "Paid", and the APP pushes a notification that "Payment successful, electronic ticket generated".

[0143] After the order status is updated to "paid", the blockchain order management module sends a trigger command to the integrated support module:

[0144] The meal reservation system recommends a hot meal set meal (matching the user's historical preference for "Sichuan and Hunan cuisine") based on the 8:30 flight time slot (3-hour journey) and displays "estimated delivery to seat at 10:00".

[0145] Based on arrival time in Guangzhou (11:30) and transportation time (30 minutes), the hotel booking system recommends partner hotels near Baiyun Airport (latest check-in time ≥ 12:30).

[0146] After the recommendation results are integrated by the information processing server, they are pushed to the user via an app pop-up window, containing "Blockchain Evidence ID: xxxx" for verification.

[0147] Airport Verification: When a user arrives at Beijing Capital International Airport, they undergo facial recognition verification at the boarding gate (connected to the public security facial database, recognition is successful in 0.4 seconds). The ticket verification module compares the information with the blockchain order information (order status "paid", identity matches), returns "verification passed", the gate opens, the order status is updated to "verified" and recorded on the blockchain.

[0148] Refund Processing: If a user applies for a refund for one person's ticket (full-price economy class ticket P = 1800 yuan, K = 0.1, T = 48 hours, t = 48 hours) due to a change in travel itinerary, the refund amount will be calculated as follows: F = 1800 × 0.1 × (1 - (48 - 48) / 48) = 180 × 1 = 180 yuan. The refund amount will be 1800 - 180 = 1620 yuan. The smart contract will complete the fee calculation and refund initiation within 3 minutes. The digital RMB refund will arrive in 10 minutes, and the order status will be updated to "refunded" and recorded on the blockchain.

[0149] III. Performance Verification Form

[0150]

[0151]

[0152] The table is based on 3-day measured data during the Spring Festival, and the traditional system has a single-day order peak of only 60,000 orders due to the centralized architecture, a payment response of more than 4 seconds, and a data consistency of less than 90%, resulting in 15% of users encountering "displaying remaining tickets but unable to book"; ticket refund requires manual verification, taking more than 10 minutes. The present application uses a blockchain distributed architecture, with an order peak of 150,000 orders, a payment response time of 3 seconds, a data consistency of more than 99.8%, and automatic processing of ticket refunds, taking less than 3 minutes. For example, on January 25th at 10:00, the traditional system had 2 times of lag, while the present application had no lag, with an order chaining success rate of 99.95%, and only 3 orders successfully retried after network fluctuations, fully adapting to the high-concurrency scenario of the Spring Festival and ensuring user travel efficiency.

[0153] Embodiment 3

[0154] Cross-border railway electronic ticket booking and payment (China-Europe train passenger transport scenario)

[0155] I. System deployment and module configuration

[0156] User interaction module: Official PC terminal (compatible with Chrome 120.0) and mobile APP (supports English / Chinese switching) of China-Europe train are used, with English interface terms translated by localization ("seat class" is translated as "SeatClass", and "change booking" is translated as "ChangeBooking"). The query function is filtered according to "departure city (Chongqing)-destination city (Duisburg)-date (March 10, 2025)-seat class (SecondClass)", and the data of the blockchain remaining ticket pool of the China-Germany railway system is called, with a loading time of 0.7 seconds; the booking function supports 2-person cross-border ordering, and user information is stored after desensitization (passport number only shows the first and last 2 digits, such as "E****89"); the multi-language switching button is placed in the upper right corner of the interface, and the interface language is refreshed within 1 second after clicking; the operation log is synchronized to the blockchain storage module.

[0157] Blockchain order management module: 10 consensus nodes are deployed (2-3 in Chongqing and Chengdu, Germany Duisburg and Berlin), PBFT consensus mechanism, block generation interval 2.8 seconds. The order generation unit integrates cross-border travel information (Chongqing West Station-Duisburg Station, March 10, 2025, 10:00, second class seat), user passport hash value, and payment currency (Euro), generates order number "UUID-75412", and after SHA-256 hashing, it is chained; the status update unit needs to be verified by 7 nodes, and the cross-border order status update delay is ≤1.2 seconds; the query unit supports query by order number or passport number hash, and the result contains bilingual status description ("paid" corresponds to "Paid").

[0158] Multi-modal payment and multi-currency adaptation: Legal currency payment connects with UnionPay (RMB) and Visa (Euro), digital currency payment connects with digital RMB and Eurozone digital Euro prototype; Exchange rate is obtained from the European Central Bank every 5 minutes, with an error of ≤0.01% (e.g. 1 Euro ≈ 7.8 RMB). User selects 2 people to pay in Euro (second-class seat single price 150 Euro / person), payment instruction is encrypted by AES-256, Visa payment response is 2.8 seconds; Multi-currency conversion unit automatically calculates the amount (150 Euro x 2 = 300 Euro ≈ 2340 RMB), APP displays "Total: 300 EUR (≈2340 CNY)", after payment is completed, payment voucher is chained, and is synchronized to the Sino-German railway settlement system.

[0159] Key formula application:

[0160] Refund fee calculation: User applies for 1 person refund (second-class seat P = 150 Euro, discount rate 85%, K = 0.2, T = 72 hours, t = 72 hours) due to visa issues 72 hours before departure, then F = 150 x 0.2 x (1 - (72 - 72) / 72) = 30 x 1 = 30 Euro, refund amount = 150 - 30 = 120 Euro, smart contract initiates Visa refund in 2.5 minutes, 36 hours to arrive (regular time limit for cross-border payment), order status is updated to "Refund" and chained.

[0161] Order risk assessment: Overseas user historical credit score H = 85 (no default, α = 0.4), order contains "cross-border IP (ordered under German IP) + commonly used equipment" (O = 30, β = 0.35), ordered 120 hours before departure (T = 10, γ = 0.25), then R = 0.4 x 85 + 0.35 x 30 + 0.25 x 10 = 34 + 10.5 + 2.5 = 47 (low risk), order is directly passed without the need for secondary verification.

[0162] II. Complete business process implementation

[0163] Cross-border ordering and chaining: German user opens English interface APP, queries second-class seat from Chongqing to Duesseldorf on March 10, 0.7 seconds to load 12 remaining tickets, selects 2 people to order, fills in passport information (de-sensitization storage), after submitting the order, blockchain order management module generates order number and chains it within 1.1 seconds, interface displays "OrderCreated, PendingPayment".

[0164] Multi-currency payment: User selects Visa Euro payment, APP displays 300 Euro (≈2340 RMB), payment instruction is encrypted and transmitted, payment is completed after 2.8 seconds, payment voucher is synchronized to the Sino-German railway node, order status is updated to "Paid", and English confirmation SMS is pushed.

[0165] After payment is completed, the comprehensive supporting module receives the "paid" instruction:

[0166] The travel booking system extracts the "Duisburg" destination hash from the order and calls the local travel interface to recommend Cologne Cathedral tickets (matching arrival time 14:00, recommended 15:30 session);

[0167] Based on the "cross-border business trip" label, the life e-commerce platform recommends a portable translation device, showing "Duisburg station pickup point, 2 hours away";

[0168] The recommendation record is written into the Sino-German consensus node after SHA-256 hashing, and users can query the recommendation traceability information through the order number.

[0169] Cross-border verification: the user arrives at Chongqing West Railway Station and verifies through NFC near-field communication (mobile phone NFC close to the gate, 0.5 seconds to read the order hash), the ticket verification module compares the blockchain order (status "Paid", passport information consistent), returns "verification passed", the gate is released, and the order status is updated to "Verified" and chained.

[0170] Data synchronization: after the user places an order on the China-Europe Train APP, the order data is synchronized to the German railway DB system within 1 second, and the user can query the order on the DB website (displaying "Chongqing-Duisburg, 10Mar, SecondClass"). The remaining ticket pool is reduced by 2 second-class seats, ensuring consistent data between Sino-German platforms.

[0171] III. Performance verification table

[0172]

[0173]

[0174] This table is based on one month of cross-border operation data of the China-Europe Train, the traditional system only supports Sino-German bilingual, RMB / Euro dual currency, cross-border orders without blockchain evidence, and the synchronization delay is more than 5 seconds, resulting in 20% of users unable to find the China-Europe Train APP order on the DB website; cross-border ticket refund takes more than 72 hours, and the user experience is poor. This invention supports 12 languages and 20 currencies, cross-border orders are chained within 1.5 seconds, synchronization delay is within 1.2 seconds, data consistency is more than 99.8%, and refund is within 48 hours, and the order can be traced throughout (Sino-German users can query the blockchain evidence). For example, on March 5, a German user placed an order on the APP, and within 1 second, the DB website showed the order, and after payment, it was chained within 2.8 seconds, and the verification was passed within 0.5 seconds, fully solving the language, currency, and data synchronization problems in cross-border scenarios, and improving the convenience of cross-border travel.

[0175] Figure 2 The optimization value of blockchain technology for ticketing system is highlighted. The traditional centralized system has a data centralized storage, a tampering risk of more than 15%, a payment account need of more than T+1, a synchronization delay of more than 8 seconds, and a high privacy leakage rate; after introducing the blockchain, the tampering risk is reduced to below 0.5%, the account period is shortened to T+1, but the synchronization delay and the leakage rate still have optimization space. The application further optimizes on the basis of the blockchain: the tampering risk is reduced to 0.01% by distributed consensus nodes, the fund settlement is accelerated to T+0.5 by smart contract, the leakage rate is reduced to below 0.5% by zero-knowledge proof, the synchronization delay is reduced to 1.2 seconds, the verification success rate is more than 99.8%, and the problems of "poor safety, low efficiency, and weak privacy" of the traditional system are solved, which is suitable for high safety demand scenarios of aviation and railway.

[0176] Figure 3 The chart focuses on the efficiency of the whole life cycle of the order. The traditional system relies on manual verification and interaction with the centralized server, and it takes 8 seconds from order generation to payment pending, and more than 25 seconds for ticket refund process, which is low in efficiency; after introducing the blockchain, the time consumption is shortened by data chaining, but it still takes more than 3 seconds to complete the payment status update. The application optimizes through module cooperation: the blockchain order management module generates an order within 1.5 seconds, the multi-modal payment module completes payment verification within 3 seconds, the ticket verification module completes verification within 1 second, and the smart contract processes ticket refund within 2-3 seconds. The time consumption of each link is much lower than that of the traditional and basic blockchain system. For example, in the ticket refund link, the traditional system needs manual audit for 25 seconds, and the application automatically calculates the service charge and updates the status through the preset contract, which takes only 3 seconds, significantly improving the efficiency of user travel and adapting to the high concurrency demand of aviation and railway peak period.

[0177] Figure 4 The chart reflects the iterative upgrade of the payment method. The traditional payment method uses magnetic stripe encryption for bank cards (low security), does not support digital currency, has a cross-border payment exchange rate delay, and a failure rate of more than 1.5%; after introducing the blockchain, the bank card is upgraded to EMV encryption, and supports real-time exchange rate cross-border payment, but still does not support digital currency and offline payment. The application extends on the basis of the two: the bank card uses EMV+AES-256 double encryption, the third-party payment is upgraded to TLS1.3, and fully supports digital renminbi (including offline payment) and compliant cross-border digital currency, with an encryption level reaching the national standard, and a failure rate of less than 1.5%. For example, the traditional system does not support digital renminbi payment, the application supports offline payment, and automatically synchronizes on-chain after going online, with a failure rate of only 0.8%, which not only meets the convenient payment needs of domestic users, but also adapts to the multi-currency scenario of cross-border travel, solving the problem of single payment method and insufficient security.

[0178] The above merely describes preferred embodiments of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can make equivalent replacements or changes within the technical scope disclosed by the present application and according to the technical solutions and inventive concept of the present application, which should be covered within the protection scope of the present application.

Claims

1. A blockchain-based electronic ticketing and payment application system, characterized in that, include: The system includes a user interaction module, a blockchain order management module, a multimodal payment module, a ticket verification module, a data storage module, and comprehensive supporting modules. The integrated supporting system includes a restaurant reservation system, a tourism reservation system, a hotel reservation system, a convenient payment system, and a lifestyle e-commerce platform. User interaction module: Provides users with multi-terminal operation entry points, supporting access from mobile terminals, PCs, and smart terminals; supports ticket inquiry, batch ordering, ticket change and refund operations, and user information is stored in an anonymized manner; The blockchain order management module is responsible for the on-chain data and management of the entire lifecycle of orders. It includes an order generation unit, a status update unit, and a query unit: After receiving an order request, the order generation unit integrates itinerary, user, and payment information to generate a unique number, which is then written to the blockchain after being processed by the SHA-256 hash algorithm; The status update unit updates the status according to the ticket process, and changes require verification by at least 3 consensus nodes; The query unit supports querying by order number, ID number hash value, and encrypted mobile phone number value, including complete status flow records and block hashes. The multimodal payment module supports dual-track payment of fiat currency and digital currency, and includes encrypted transmission and payment verification units: the encrypted transmission unit uses AES-256 to encrypt payment instructions, and the data is only visible to the two parties to the payment and the necessary consensus nodes; after receiving the result, the payment verification unit generates a certificate and puts it on the blockchain, and automatically triggers a refund pre-application and notifies the user when the payment fails; The ticket verification module enables rapid verification in multiple scenarios, including an identity verification unit: the identity verification unit compares the verification information with the blockchain order information to verify validity and consistency; the result feedback unit returns the verification result, synchronously updates the order to "verified" and uploads it to the blockchain; The data storage module stores key data and adopts a "hash on-chain + distributed storage" architecture: key data is written to the blockchain using SHA-256 hash, and the original data is encrypted and stored in distributed nodes. The validity period of the storage is consistent with that of the ticket. The integrated supporting module is connected to the blockchain order management module and includes: Meal reservation system: intelligently recommends airline and train meals based on travel time; Travel booking system: Links with travel destinations to provide attraction ticket services; Hotel booking system: Recommends hotels based on departure / arrival time; Convenient payment system: Supports one-stop payment of water, electricity, gas and other bills; Lifestyle e-commerce platform: Provides instant delivery service for travel essentials; When the order status is updated to "paid", related complementary service recommendations will be automatically triggered.

2. The blockchain-based electronic ticketing and payment application system according to claim 1, characterized in that, It also includes an order risk assessment unit, which calculates the order risk value through multi-dimensional parameters. The risk assessment formula is as follows: R=α×H+β×O+γ×T; In the formula, R is the order risk value, α is the user's historical credit weight, H is the user's historical credit score, β is the order anomaly coefficient weight, O is the order anomaly coefficient, γ is the time-sensitive weight, and T is the time-sensitive coefficient. A blockchain node cluster, which is connected to the blockchain order management module, is used to provide distributed consensus verification.

3. The blockchain-based electronic ticketing and payment application system according to claim 1, characterized in that, It also includes a ticket rescheduling optimization unit. This unit has a pre-set ticket rescheduling rule library. When a user submits a rescheduling application, the system first verifies whether it meets the rules. If the rescheduling application meets the rules, the user selects the target train / flight, date, and cabin / seat class. The system verifies the target ticket availability status in real time through the blockchain data synchronization unit. If the availability is valid, the system automatically calculates the price difference between the original ticket and the new ticket and generates a price difference payment instruction through the multimodal payment module. After the user completes the price difference payment, the system freezes the original ticket status as "rescheduled" and records it on the blockchain. At the same time, it integrates the new itinerary information to generate a unique new order number, processes it, and writes it to the blockchain. The new order status has been updated to "Rescheduled - Valid"; The rescheduling rules include: rescheduling time limit, number of rescheduling attempts, and restrictions on cabin / seat class changes; if a user reschedules to a train / flight with no available tickets for the day, the system will automatically recommend similar itineraries within the next 72 hours and indicate the availability of tickets.

4. The blockchain-based electronic ticketing and payment application system according to claim 1, characterized in that, It also includes a payment settlement optimization unit, which is mainly used to optimize the settlement delay of blockchain node collaboration and data transmission paths; the settlement delay optimization formula is as follows: In the formula, E represents the settlement delay, A represents the total amount of a single settlement, S represents the node collaboration coefficient, N represents the number of nodes participating in the settlement, and D represents the average network delay.

5. The blockchain-based electronic ticketing and payment application system according to claim 1, characterized in that, It also includes a user privacy protection unit, which adopts a three-level protection mechanism. The first level of protection is that when a user verifies a ticket, only proof that the user is the owner of the order needs to be generated. The verification terminal verifies the validity of the proof through the blockchain without obtaining the original privacy data. The second level of protection is that the original data is stored on an offline cold node using a homomorphic encryption algorithm and is decrypted only when the user initiates information modification. The third level of protection is to control access based on system roles. All permission changes of system roles are logged and uploaded to the blockchain.

6. The blockchain-based electronic ticketing and payment application system according to claim 1, characterized in that, It also includes an internal data synchronization unit, which adopts a "blockchain distributed ledger + incremental synchronization" mechanism: each functional consensus node acts as a consensus node of the blockchain, and obtains order, remaining tickets, and payment data in the ledger in real time; the synchronization content includes remaining ticket updates, order status synchronization, and payment result synchronization; Payment results are pushed to all nodes in real time. The payment voucher is broadcast to all nodes within 200ms after it is uploaded to the blockchain. If different platforms update the status of the same order at the same time, the update request with the earlier timestamp shall prevail. If the timestamp difference is ≤100ms, it shall be submitted to the consensus node for voting.

7. The blockchain-based electronic ticketing and payment application system according to claim 1, characterized in that, It also includes a smart contract auto-fulfillment unit, which presets fulfillment rules for ticket refund and rescheduling scenarios. When a user submits a ticket refund request, the smart contract auto-fulfillment unit verifies whether it meets the refund rules. When the smart contract auto-fulfillment unit determines that it meets the refund rules, it calculates the handling fee and the refund amount. Based on the refund amount, the smart contract auto-fulfillment unit initiates the refund to the user's payment account, updates the order status to "refunded" and records it on the blockchain. After the refund order is recorded on the blockchain, the smart contract auto-fulfillment unit pushes a ticket refund success and refund notification to the user.

8. The blockchain-based electronic ticketing and payment application system according to claim 3, characterized in that, It also includes a ticket traceability unit, which relies on the blockchain's chain storage structure to achieve full-process traceability of tickets. Users can query their ticket traceability records by order number. The ticket traceability unit traces data by time period, ticket type, and operating entity.

9. The blockchain-based electronic ticketing and payment application system according to claim 5, characterized in that, It also includes a system load balancing unit, which dynamically allocates resources by monitoring system resource usage and user access volume in real time. The load balancing adjustment strategy is that when the load monitoring indicators exceed the warning threshold, the system load balancing unit automatically starts the backup server and dispatches some user requests to regional nodes with lower load.

10. The blockchain-based electronic ticketing and payment application system according to claim 4, characterized in that, It also includes a multi-language and multi-currency adaptation unit. When making a payment, the user selects the original currency or the target currency, and the system automatically calculates and displays the conversion amount. After the payment is completed, the settlement amount is converted into the settlement currency according to the median exchange rate of the day.

11. The blockchain-based electronic ticketing and payment application system according to claim 1, characterized in that, It also includes a distributed node health monitoring and self-healing unit, which works in conjunction with the blockchain node cluster and the system load balancing unit to monitor the running status of consensus nodes and the effectiveness of data synchronization in real time. The monitoring indicators include: node CPU utilization, memory usage, data synchronization rate, and consensus response latency. When a node indicator triggers an alert, the unit automatically determines the fault type: if it is a resource overload, it calls the system load balancing unit to start a backup node and generates a node switching log during the migration process; if it is a synchronization anomaly, it automatically triggers a data retransmission mechanism and verifies data consistency after the retransmission is completed. After the fault handling is completed, the unit will encrypt the fault information and node operation logs and upload them to the blockchain for evidence storage. At the same time, it will push the node health report to the technical maintenance role terminal. In addition, the unit supports the generation of node cluster health trend charts on a daily basis. The chart data is written to the data storage module after being hashed.

12. The blockchain-based electronic ticketing and payment application system according to claim 1, characterized in that, It also includes a regulatory intelligent early warning unit, which works in conjunction with the data storage module and the blockchain order management module to build a multi-dimensional regulatory analysis model based on real-time blockchain data. The analysis model includes: abnormal order cluster identification dimension, abnormal payment fluctuation dimension, and verification anomaly dimension. When data in a certain dimension triggers a preset threshold, the unit automatically generates an early warning message and pushes it to the corresponding regulatory agency's terminal through an encrypted channel; at the same time, it calls the data storage module to generate a phased regulatory audit report, which is then uploaded to the blockchain for storage in real time; in addition, the unit supports regulatory agencies to customize early warning thresholds and analysis dimensions, and the customized rules are written into the smart contract to take effect after being verified by the consensus node.

13. The blockchain-based electronic ticketing and payment application system according to claim 1, characterized in that, It also includes a special group service adaptation unit, which works in conjunction with the user interaction module and the ticket verification module to provide exclusive service functions for special groups such as elderly users and disabled users; In terms of user interaction: it supports voice interaction, large font interface, and simplified operation process; Regarding ticket verification: new functions have been added for iris recognition-assisted verification and a green channel for manual verification. At the service integration level: special service appointments are automatically linked. After the user completes the order, the system pushes the appointment request to the special service department. The feedback result is synchronized to the user terminal within 30 seconds and stored on the blockchain. All operation logs of special groups are anonymized and separately classified and archived in the data storage module.

Images