Blockchain-based tracing method and system for service node switching

Abstract

The present application belongs to the technical field of communications, and discloses a blockchain-based tracing method and system for service node switching. The method comprises: constructing a blockchain network; when a user moves from a signal coverage range of a first base station to a signal range of a second base station, recording service node switching information by means of the first base station; using the first base station as a user node in the blockchain network to submit the service node switching information to the blockchain network; broadcasting a consensus message to the blockchain network by means of a main node in the blockchain network; performing independent verification on the consensus message by means of a replica node in the blockchain network, and when the verification is successful, continuing forwarding the consensus message to other nodes; voting by means of a plurality of consensus nodes, and when more than the preset proportion of consensus nodes cast approval votes, reaching a consensus and adding the consensus message into a blockchain; and querying in the blockchain network to trace a service node switching record of a target user.

Description

A blockchain-based traceability method and system for service node switching

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on December 5, 2023, with application number 202311656911.5 and invention name “A traceability method and system for service node switching based on blockchain”, the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application belongs to the field of communication technology, and specifically relates to a blockchain-based service node switching traceability method and system. Background Art

[0004] With the development of wireless communications, the number of users accessing the 5G network has increased exponentially, and the deployment of 5G base stations is also very dense. Due to the frequent movement of a large number of users, a large number of service base station switching records have been generated in the network, resulting in data reliability, consistency, data integrity, data security and fault tolerance issues for faulty nodes in the switching records, making it impossible to guarantee the correctness of the traceability data.

[0005] Service node switching records are crucial for network management and performance optimization. First, they enable detailed tracking of the process and reasons behind each switch. This is crucial for network operators and regulators, helping them understand network operations, troubleshoot issues, and optimize network performance, ultimately providing more stable and efficient services. Second, these records play a crucial role in troubleshooting and recovery. When a network failure occurs, these switchover records help operators quickly locate the root cause, reducing repair time and minimizing the impact of network outages on users. Most importantly, these switchover records involve data security and privacy protection. As switchover records are critical network data, their security and integrity must be guaranteed to prevent tampering, loss, and unauthorized access.

[0006] Some existing technologies, such as patents CN110677280A and CN114785531A, address the issue of establishing secure communication links between nodes. However, these technologies overlook the lack of a decentralized consensus mechanism in traditional centralized network structures, which can lead to inconsistent consensus on handover records. Existing technologies also lack immutability and data sharing. Data records stored in a single centralized database are vulnerable to attacks and single points of failure, compromising the security of handover records. Furthermore, existing technologies lack data traceability, making it impossible to fully understand the source and direction of each service node handover. Summary of the Invention

[0007] In order to solve the problem that the existing technology ignores the lack of a decentralized consensus mechanism in the traditional centralized network structure, which may lead to inconsistent consensus on switching records, the existing technology also lacks the characteristics of immutability and data sharing. Data records stored in a single centralized database are vulnerable to attacks and single point failures, thereby affecting the security of switching records. The existing technology also lacks data traceability functions and cannot fully understand the source and direction of each service node switch. Technical problems, this application provides a blockchain-based service node switching traceability method and system.

[0008] First aspect

[0009] This application provides a blockchain-based service node switching traceability method, including:

[0010] S1: Use base stations as distributed consensus nodes to build a blockchain network;

[0011] S2: When the user moves from the signal coverage of the first base station to the signal coverage of the second base station, the first base station records the service node switching information;

[0012] S3: Submitting the service node switching information to the blockchain network by using the first base station as a user node in the blockchain network;

[0013] S4: Encapsulating the plurality of service node switching information from the user node into a consensus message through the master node in the blockchain network, and broadcasting the consensus message to the blockchain network;

[0014] S5: The consensus message is independently verified by the replica nodes in the blockchain network. When the verification passes, it is forwarded to other nodes.

[0015] S6: Voting is performed by multiple consensus nodes. When more than a preset proportion of consensus nodes cast affirmative votes, a consensus is reached and the consensus message is added to the blockchain.

[0016] S7: By querying in the blockchain network, the service node switching record of the target user is traced.

[0017] Optionally, the first base station is configured with a corresponding edge computing server as a user node, and the edge computing server is used to encapsulate and broadcast transactions of service node switching information.

[0018] Optionally, the consensus message includes block information, a digital signature, and a message summary.

[0019] Optionally, the S5 specifically includes:

[0020] S501: Determine, through the replica node in the blockchain network, whether the message type of the consensus message is the current execution stage; if so, proceed to the next step; otherwise, verification fails;

[0021] S502: Determine whether the view number of the consensus message is consistent with the current view number of the node; if so, proceed to the next step; otherwise, verification fails;

[0022] S503: Determine whether the sequence number of the consensus message is valid; if so, proceed to the next step; otherwise, verification fails;

[0023] S504: Determine whether the timestamp of the consensus message is reasonable; if so, proceed to the next step; otherwise, verification fails;

[0024] S505: Determine whether the digital signature of the consensus message is valid; if so, proceed to the next step; otherwise, verification fails;

[0025] S506: Obtain the private key corresponding to the public key ID and use the private key to verify whether the signature in the message is consistent; if so, proceed to the next step; otherwise, the verification fails;

[0026] S507: Calculate the digest of the consensus message according to the digest algorithm, and compare the calculated digest with the digest recorded in the consensus message to see if they are consistent; if so, verification succeeds; otherwise, verification fails.

[0027] Optionally, the blockchain network adopts a PBFT consensus mechanism. When more than 2 / 3 of the consensus nodes cast affirmative votes, a consensus is reached and the consensus message is added to the blockchain.

[0028] Second aspect

[0029] This application provides a blockchain-based service node switching traceability system, including:

[0030] A building block for building a blockchain network using base stations as distributed consensus nodes.

[0031] a recording module, configured to record service node switching information through the first base station when a user moves from a signal coverage area of ​​a first base station to a signal coverage area of ​​a second base station;

[0032] A submission module, configured to submit the service node switching information to the blockchain network by using the first base station as a user node in the blockchain network;

[0033] A broadcast module, configured to encapsulate the plurality of service node switching information from the user node into a consensus message through a master node in the blockchain network, and broadcast the consensus message to the blockchain network;

[0034] A verification module, configured to independently verify the consensus message through replica nodes in the blockchain network, and forward it to other nodes when the verification passes;

[0035] A voting module is used to vote through multiple consensus nodes. When more than a preset proportion of consensus nodes cast affirmative votes, a consensus is reached and the consensus message is added to the blockchain.

[0036] The traceability module is used to trace the service node switching record of the target user by querying in the blockchain network.

[0037] Optionally, the first base station is configured with a corresponding edge computing server as a user node, and the edge computing server is used to encapsulate and broadcast transactions of service node switching information.

[0038] Optionally, the consensus message includes block information, a digital signature, and a message summary.

[0039] Optionally, the verification module is specifically configured to:

[0040] Determine, through the replica node in the blockchain network, whether the message type of the consensus message is the current execution stage; if so, proceed to the next step; otherwise, the verification fails;

[0041] Determine whether the view number of the consensus message is consistent with the current view number of the node; if so, proceed to the next step; otherwise, verification fails;

[0042] Determine whether the sequence number of the consensus message is valid; if so, proceed to the next step; otherwise, verification fails;

[0043] Determine whether the timestamp of the consensus message is reasonable; if so, proceed to the next step; otherwise, verification fails;

[0044] Determine whether the digital signature of the consensus message is valid; if so, proceed to the next step; otherwise, verification fails;

[0045] Obtain the private key corresponding to the public key ID and use the private key to verify whether the signature in the message is consistent; if so, proceed to the next step; otherwise, the verification fails;

[0046] According to the digest algorithm, the digest of the consensus message is calculated and compared with the digest recorded in the consensus message to see if they are consistent; if so, the verification succeeds; otherwise, the verification fails.

[0047] Optionally, the blockchain network adopts a PBFT consensus mechanism. When more than 2 / 3 of the consensus nodes cast affirmative votes, a consensus is reached and the consensus message is added to the blockchain.

[0048] Compared with the prior art, this application has at least the following beneficial technical effects:

[0049] In this application, the decentralized consensus mechanism and immutability of blockchain technology ensure that most nodes reach consensus on service node switching information, enhancing the security, reliability, and transparency of service node switching information. By querying the blockchain network, the target user's service node switching records can be traced, achieving a comprehensive understanding of the source and direction of each service node switch. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] The preferred implementation scheme will be described below in a clear and understandable manner with reference to the accompanying drawings to further illustrate the above-mentioned characteristics, technical features, advantages and implementation methods of the present application.

[0051] FIG1 is a flow chart of a blockchain-based traceability method for switching service nodes provided in this application.

[0052] Figure 2 is a timing flow chart of a blockchain-based service node switching traceability method provided by this application.

[0053] FIG3 is a schematic structural diagram of a blockchain-based service node switching traceability system provided in this application. DETAILED DESCRIPTION

[0054] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the specific implementation methods of the present application will be described below with reference to the accompanying drawings. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings and other implementation methods can be obtained based on these drawings without inventive work.

[0055] To simplify the drawings, only portions relevant to the invention are schematically depicted in each figure; they do not represent the actual structure of the product. Furthermore, to simplify the drawings and facilitate understanding, in some figures, only one component with the same structure or function is schematically depicted or labeled. In this document, "one" not only means "only one" but also "more than one."

[0056] It should be further understood that the term "and / or" used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

[0057] It should be noted that, unless otherwise specified or limited, the terms "mounted," "connected," and "connected" should be understood broadly. For example, they can refer to fixed connections, removable connections, or integral connections. They can refer to mechanical connections or electrical connections. They can refer to direct connections or indirect connections through an intermediary, or they can refer to internal communication between two components. Those skilled in the art will understand the specific meanings of these terms in this application based on the specific circumstances.

[0058] In addition, in the description of the present application, the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0059] Example 1

[0060] In one embodiment, referring to FIG1 of the specification, a flowchart of a blockchain-based service node switching traceability method provided by the present application is shown.

[0061] Referring to Figure 2 of the specification, a timing flow chart of a blockchain-based service node switching traceability method provided by the present application is shown.

[0062] This application provides a blockchain-based service node switching traceability method, including:

[0063] S1: Use base stations as distributed consensus nodes to build a blockchain network.

[0064] Optionally, the blockchain network consists of multiple base stations and multiple connected users.

[0065] Base station equipment typically includes indoor and outdoor base stations, which are used to provide wide-area coverage and small-area coverage. Base station equipment is a communication device that is usually installed at a high point or in a specific area to provide optimal wireless signal coverage.

[0066] Optionally, the base station is equipped with an edge computing server, which has certain computing and storage capabilities in addition to communication capabilities.

[0067] It should be noted that edge computing servers, using cloud computing technology, serve as computing devices for blockchain nodes. They are installed near base stations and are used to implement edge computing functions and the data encapsulation, consensus, and on-chain processes of blockchain nodes. Edge computing servers can be dedicated servers or general-purpose server configurations.

[0068] Optionally, base station nodes are connected via a point-to-point network, forming a decentralized blockchain network. Edge computing servers and base station nodes are connected via a dedicated network or local area network to achieve data transmission and exchange.

[0069] Optionally, the blockchain network adopts a PBFT consensus mechanism based on a consortium chain. This consensus mechanism has high decentralization capabilities, high throughput efficiency, and consumes less computing resources, making it very suitable for operators to build blockchain networks.

[0070] It should be noted that in the blockchain network, each base station is both an access node for users during communication and a distributed consensus node with blockchain on-chain functionality.

[0071] Optionally, during the PBFT consensus process, node roles will be divided into three types: user nodes, master nodes, and replica nodes.

[0072] Among them, the user node refers to the base station responsible for recording information and sending it to the master node during the process of the service node switching and recording consensus.

[0073] The master node is responsible for packaging data into blocks and coordinating the initiation and execution of the entire consensus process. Each view corresponds to a master node, which is elected in turn by nodes in each view to ensure system reliability and fairness.

[0074] Among them, replica nodes refer to nodes other than user nodes and master nodes in the blockchain consensus. Replica nodes are responsible for receiving messages from master nodes and other replica nodes, and verifying and processing the messages.

[0075] It should be noted that the technical solution for service node switching records involves the software architecture of the wireless transmission layer and the blockchain network layer. These two layers together constitute the infrastructure of the entire system. The following is a detailed description of these two layers:

[0076] For the wireless transmission layer: The wireless transmission layer involves the software architecture of base station nodes and edge computing servers. These nodes are responsible for encapsulating and broadcasting user access and service node handover records.

[0077] Base station node software architecture: The base station node is responsible for receiving users' wireless connection requests and providing wireless communication services. It also serves as a node in the blockchain network, participating in the consensus algorithm and data on-chain. In the base station node, the following functional modules need to be implemented:

[0078] (1) Communication module: responsible for receiving user connection requests, processing communication data transmission, and communicating with other base station nodes and edge computing servers.

[0079] (2) Data encapsulation module: When a user's service node switches, the base station node encapsulates the switching record into a transaction and signs the transaction with a digital signature to ensure the integrity and authenticity of the data.

[0080] (3) Blockchain connection module: As a node of the blockchain network, the base station node needs to connect to the blockchain network and participate in the consensus algorithm to maintain the consistency of the entire blockchain.

[0081] Edge computing server software architecture: As the computing device of the blockchain node, the edge computing server is responsible for encapsulating the service node switching records and broadcasting transactions. In the edge computing server, the following functional modules need to be implemented:

[0082] (1) Blockchain information processing module: The edge computing server needs to verify and upload the blockchain messages received by the base station.

[0083] (2) Data encapsulation module: After the base station node generates the handover record request consensus, the edge computing server is responsible for receiving these records and requests, packaging them into blocks, and then broadcasting them to the entire blockchain network.

[0084] The blockchain network layer mainly involves the blockchain's consensus algorithm, smart contracts, and data storage, which form the core part of the distributed service node switching record.

[0085] Consensus Algorithm: The technical solution incorporates the PBFT consensus algorithm, which allows nodes in the network to reach consensus on the status of transactions without the need for centralized control. Every node can participate in the consensus process and verify the legitimacy of transactions. This ensures the consistency and authenticity of each transaction record.

[0086] Smart contracts: Automates and standardizes operations such as node joining and deletion, helps control the node joining and exit process, and provides a more transparent, secure, and trustworthy way to manage nodes, thereby enhancing the stability and reliability of the entire system.

[0087] Data storage: Each node in the blockchain network has a complete copy of the blockchain data, recording all switching transactions and node information. This data is stored in a chain structure and verified and added through the consensus algorithm to ensure data security and integrity.

[0088] S2: When the user moves from the signal coverage of the first base station to the signal coverage of the second base station, the first base station records the service node switching information.

[0089] In a possible implementation, the first base station as a user node is configured with a corresponding edge computing server, and the edge computing server is used to encapsulate and broadcast transactions of service node switching information.

[0090] It should be noted that when a user moves to the signal coverage of another base station, base station A will record key information of the switch, including the switch time, user identity, signal strength, and the switch from base station A to base station B.

[0091] In this application, by recording service node handoff information, the system can track the process of users moving from one base station to another. This allows for smoother service node handoffs as users move, providing a better user experience and reducing the likelihood of communication and service interruptions. Furthermore, recording handoff information facilitates effective resource management and load balancing. Operators can adjust network resource allocation based on handoff information, ensuring that each base station can effectively handle user traffic and preventing overloading of certain base stations, which can lead to degraded service quality.

[0092] S3: Using the first base station as a user node in the blockchain network, submit the service node switching information to the blockchain network.

[0093] It's important to note that service node switching information is encoded as a transaction, and user identities are encrypted to ensure data security and integrity. This transaction information is submitted by Base Station A, acting as a user node in the blockchain's PBFT consensus mechanism. The switching information is securely stored in the immutable blockchain and can be accessed at any time by authorized participants. This allows for user movement tracing, network performance optimization, and regulatory and operational needs. Furthermore, to protect privacy, user identities can be appropriately encrypted to ensure data security and integrity.

[0094] Through this approach, service node switching information is securely stored in an immutable blockchain and can be accessed at any time by authorized participants. This information can be used to track user movements, optimize network performance, and meet regulatory and operational requirements. Furthermore, to protect privacy, user identities can be appropriately encrypted to ensure data security and integrity.

[0095] S4: Through the master node in the blockchain network, multiple service node switching information from the user node is encapsulated into a consensus message, and the consensus message is broadcast to the blockchain network.

[0096] Among them, the consensus message includes block information, digital signature and information summary.

[0097] Specifically, the base station acting as the master node receives service node switching information recorded by other base stations and stores it in the transaction pool. It takes out multiple switching records from the information pool at regular intervals, encapsulates them into block data format and packages them into PBFT consensus messages, and then broadcasts them to the entire blockchain network.

[0098] The block encapsulation format is as follows: Each block consists of two parts: a block header and a block body. The block header contains the hash value of the previous block, the root hash value of the current block, and timestamp information. The block body contains a service node switch record, which is a collection of one or more service node switch records. Each record contains service node switch information such as the service node information before the switch, the service node information after the switch, and the switch time.

[0099] Optionally, the data format of the consensus message is<Type,View,Sequence Number,Digest,Message,Basestation ID,Timestamp,Signature> .

[0100] Type: Indicates the message type, which is an enumeration type field. Different fields are used to represent it at different stages.

[0101] View: Indicates the current view number. Each view corresponds to a master node, which is responsible for broadcasting pre-prepared messages to other nodes. The View field is used to ensure consistency among all nodes regarding the current view, preventing consensus errors caused by inconsistent views.

[0102] Sequence Number: Indicates the sequence number of the request in the current view. The master node increments the sequence number to ensure that requests are unique in each view and are processed in order.

[0103] Digest: This represents the message's digest or hash value. In the PBFT algorithm, to reduce the amount of data transmitted over the network, nodes typically transmit a digest of the request message rather than the complete request message. The digest is calculated by applying a hash function to the request content and is used to verify the integrity and consistency of the message.

[0104] Message: Indicates the block information after encapsulating the service node switching record.

[0105] Basestation ID: Indicates the ID of the base station that initiated the request for this message. In a distributed system, multiple user nodes may send consensus requests to the system at the same time. The Basestation ID can be used to distinguish the base stations that initiated the consensus requests, ensuring that each base station's request is processed correctly.

[0106] Timestamp: Indicates the timestamp of the message broadcast. The PBFT algorithm must ensure that all nodes process requests in the same order, so the timestamp is used to determine the order of requests.

[0107] Signature: This represents the digital signature of a blockchain node. When a node sends a request, it signs the request data using its private key. After receiving the request, other nodes verify the signature using the corresponding public key to ensure the request originates legitimately.

[0108] S5: The consensus message is independently verified by the replica nodes in the blockchain network. When the verification is passed, it is forwarded to other nodes.

[0109] Specifically, under the PBFT consensus algorithm, every node in the network has the right to participate in the verification and confirmation of transactions. When a node receives a transaction, it first verifies it, including checking the legitimacy of the transaction and the validity of the digital signature. The node then forwards the transaction to other nodes.

[0110] In a possible implementation, S5 specifically includes sub-steps S501 to S507:

[0111] S501: Determine whether the consensus message type is for the currently executed phase through the replica nodes in the blockchain network. If so, proceed to the next step. Otherwise, verification fails.

[0112] S502: Determine whether the view number of the consensus message is consistent with the node's current view number. If so, proceed to the next step. Otherwise, verification fails.

[0113] S503: Determine whether the sequence number of the consensus message is valid. If so, proceed to the next step. Otherwise, verification fails.

[0114] S504: Determine whether the timestamp of the consensus message is reasonable. If so, proceed to the next step. Otherwise, verification fails.

[0115] S505: Determine whether the digital signature of the consensus message is valid. If so, proceed to the next step. Otherwise, verification fails.

[0116] S506: Obtain the private key corresponding to the public key ID and use the private key to verify whether the signature in the message is consistent. If so, proceed to the next step. Otherwise, verification fails.

[0117] S507: Calculate the digest of the consensus message using the digest algorithm and compare the calculated digest with the digest recorded in the consensus message to see if they are consistent. If so, verification succeeds. Otherwise, verification fails.

[0118] In this application, by verifying the message type, view number, sequence number, timestamp, digital signature, and digest, it is possible to prevent erroneous or fraudulent messages from being mis-propagated into the blockchain network. This helps maintain the consistency and accuracy of the network.

[0119] S6: Voting is performed through multiple consensus nodes. When more than a preset proportion of consensus nodes cast affirmative votes, consensus is reached and the consensus message is added to the blockchain.

[0120] In one possible implementation, the blockchain network adopts the PBFT consensus mechanism. When more than 2 / 3 of the consensus nodes cast affirmative votes, consensus is reached and the consensus message is added to the blockchain.

[0121] Specifically, in the PBFT consensus mechanism, it is divided into the pre-preparation phase, preparation phase, submission phase and reply phase. Each node will also broadcast pre-preparation messages, preparation messages, submission messages and reply messages to other nodes in the corresponding phase to reach consensus (the specific process is shown in the attached figure). After receiving and verifying enough pre-preparation messages and preparation messages, the nodes will vote on the transaction and reach consensus through voting. When more than 2 / 3 of the nodes agree that the transaction is valid, consensus is reached and the new block is added to the blockchain, completing the confirmation and on-chain of the record. Finally, the base station will store the consensus information containing the service switching record in the database of each computing server.

[0122] The PBFT consensus mechanism effectively achieves fault tolerance for failed nodes. This is because the PBFT algorithm can tolerate failures of up to one-third of the total number of nodes in the network while maintaining system operation and consensus. This is achieved through multiple rounds of consensus message broadcasting, voting, verification, consensus, and majority decision-making between nodes. When nodes need to reach consensus, they communicate and vote with each other. Only when a sufficient number of nodes reach consensus is a transaction or decision confirmed as valid. This approach effectively protects against potential malicious behavior and issues caused by failed nodes, providing a certain level of fault tolerance for distributed systems, ensuring overall system operation even when some nodes experience problems.

[0123] In this application, the PBFT consensus algorithm is used to ensure that nodes in the blockchain reach consensus on service switching records, prevent faulty and malicious nodes from damaging records, improve consensus efficiency, and ensure the security and stability of the blockchain network. Furthermore, considering the large number of 5G service users and high throughput requirements, base stations as nodes are provided by operators, and the limited computing resources of edge computing servers, special attention is paid to node fault tolerance to ensure that even if some nodes fail or are attacked, the entire network can still reach a correct consensus and maintain the stability of service node switching records.

[0124] S7: Trace the target user's service node switching records by querying in the blockchain network.

[0125] Specifically, since switching records are stored on the blockchain, any node can trace and verify switching records. Users or network administrators can use blockchain browsers or custom query tools to find switching records for specific users, including source, flow direction, and related user information.

[0126] This application integrates data traceability with existing blockchain technology, enabling data traceability and verification through smart contracts. A permissions management mechanism is introduced to authorize users to use these functions. A security audit and monitoring mechanism is also introduced to record and monitor the operation of the data traceability function. This novel and non-obvious integration opens up a new avenue for blockchain technology to be applied in the data traceability field.

[0127] Compared with the prior art, this application has at least the following beneficial technical effects:

[0128] In this application, the decentralized consensus mechanism and immutability of blockchain technology ensure that most nodes reach consensus on service node switching information, enhancing the security, reliability, and transparency of service node switching information. By querying the blockchain network, the service node switching records of the target user can be traced, achieving a comprehensive understanding of the source and direction of each service node switch.

[0129] Example 2

[0130] In one embodiment, referring to FIG3 of the specification, a structural diagram of a blockchain-based service node switching traceability system 20 provided by the present application is shown.

[0131] This application provides a blockchain-based service node switching traceability system, including:

[0132] Construction module 201, for building a blockchain network using base stations as distributed consensus nodes;

[0133] The recording module 202 is configured to record service node switching information through the first base station when a user moves from a signal coverage area of ​​a first base station to a signal coverage area of ​​a second base station;

[0134] A submission module 203 is configured to submit the service node switching information to the blockchain network by using the first base station as a user node in the blockchain network;

[0135] A broadcast module 204 is configured to encapsulate the plurality of service node switching information from the user node into a consensus message through a master node in the blockchain network, and broadcast the consensus message to the blockchain network;

[0136] Verification module 205, configured to independently verify the consensus message through replica nodes in the blockchain network, and forward it to other nodes when the verification passes;

[0137] Voting module 206, for voting through multiple consensus nodes. When more than a preset proportion of consensus nodes cast affirmative votes, consensus is reached and the consensus message is added to the blockchain;

[0138] The tracing module 207 is used to trace the service node switching record of the target user by querying in the blockchain network.

[0139] In a possible implementation, the first base station as a user node is configured with a corresponding edge computing server, and the edge computing server is used for encapsulation and transaction broadcast of service node switching information.

[0140] In one possible implementation, the consensus message includes block information, a digital signature, and a message digest.

[0141] In a possible implementation, the verification module 205 is specifically configured to:

[0142] Determine, through the replica node in the blockchain network, whether the message type of the consensus message is the current execution stage; if so, proceed to the next step; otherwise, the verification fails;

[0143] Determine whether the view number of the consensus message is consistent with the current view number of the node; if so, proceed to the next step; otherwise, verification fails;

[0144] Determine whether the sequence number of the consensus message is valid; if so, proceed to the next step; otherwise, verification fails;

[0145] Determine whether the timestamp of the consensus message is reasonable; if so, proceed to the next step; otherwise, verification fails;

[0146] Determine whether the digital signature of the consensus message is valid; if so, proceed to the next step; otherwise, verification fails;

[0147] Obtain the private key corresponding to the public key ID and use the private key to verify whether the signature in the message is consistent; if so, proceed to the next step; otherwise, the verification fails;

[0148] According to the digest algorithm, the digest of the consensus message is calculated and compared with the digest recorded in the consensus message to see if they are consistent; if so, the verification succeeds; otherwise, the verification fails.

[0149] In one possible implementation, the blockchain network adopts a PBFT consensus mechanism. When more than two-thirds of the consensus nodes cast affirmative votes, a consensus is reached and the consensus message is added to the blockchain.

[0150] The blockchain-based service node switching traceability system provided in this application can implement the steps and effects of the blockchain-based service node switching traceability method in the above-mentioned embodiment 1. To avoid repetition, this application will not go into details.

[0151] Compared with the prior art, this application has at least the following beneficial technical effects:

[0152] In this application, the decentralized consensus mechanism and immutability of blockchain technology ensure that most nodes reach consensus on service node switching information, enhancing the security, reliability, and transparency of service node switching information. By querying the blockchain network, the target user's service node switching records can be traced, achieving a comprehensive understanding of the source and direction of each service node switch.

[0153] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0154] The above embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the scope of the present application, all of which fall within the scope of protection of the present application. Therefore, the scope of protection of this patent application shall be determined by the appended claims.

Claims

1. A blockchain-based service node switching traceability method, characterized in that: include: S1: Use base stations as distributed consensus nodes to build a blockchain network; S2: When the user moves from the signal coverage of the first base station to the signal coverage of the second base station, the first base station records the service node switching information; S3: Submitting the service node switching information to the blockchain network by using the first base station as a user node in the blockchain network; S4: Encapsulating multiple pieces of service node switching information from user nodes into a consensus message through a master node in the blockchain network, and broadcasting the consensus message to the blockchain network; S5: independently verify the consensus message through the replica nodes in the blockchain network, and when the verification passes, continue to forward it to other nodes; S6: Voting is performed through multiple consensus nodes. When more than a preset proportion of consensus nodes cast affirmative votes, a consensus is reached and the consensus message is added to the blockchain. S7: By querying in the blockchain network, the service node switching record of the target user is traced.

2. The blockchain-based service node switching traceability method according to claim 1 is characterized in that: The first base station is configured with a corresponding edge computing server as a user node, and the edge computing server is used for encapsulation and transaction broadcast of service node switching information.

3. The traceability method for service node switching based on blockchain according to claim 1 is characterized in that: The consensus message includes block information, digital signature and information summary.

4. The method for tracing the switching of service nodes based on blockchain according to claim 1 is characterized in that: The S5 specifically includes: S501: Determine, through the replica node in the blockchain network, whether the message type of the consensus message is the current execution stage; if so, proceed to the next step; otherwise, the verification fails; S502: Determine whether the view number of the consensus message is consistent with the current view number of the node; if so, proceed to the next step; otherwise, verification fails; S503: Determine whether the sequence number of the consensus message is valid; if so, proceed to the next step; otherwise, the verification fails; S504: Determine whether the timestamp of the consensus message is reasonable; if so, proceed to the next step; otherwise, the verification fails; S505: Determine whether the digital signature of the consensus message is valid; if so, proceed to the next step; otherwise, the verification fails; S506: Obtain the private key corresponding to the public key ID, and use the private key to verify whether the signature in the message is consistent; if so, proceed to the next step; otherwise, the verification fails; S507: Calculate the digest of the consensus message according to the digest algorithm, and compare the calculated digest with the digest recorded in the consensus message to see if they are consistent; if so, verification succeeds; otherwise, verification fails.

5. The method for tracing the switching of service nodes based on blockchain according to claim 1 is characterized in that: The blockchain network adopts the PBFT consensus mechanism. When more than 2 / 3 of the consensus nodes cast affirmative votes, a consensus is reached and the consensus message is added to the blockchain.

6. A blockchain-based service node switching traceability system, characterized in that: include: A building block for building a blockchain network using base stations as distributed consensus nodes; A recording module, configured to record service node switching information through the first base station when a user moves from a signal coverage range of a first base station to a signal coverage range of a second base station; A submission module, configured to submit the service node switching information to the blockchain network by using the first base station as a user node in the blockchain network; A broadcast module, used to encapsulate multiple pieces of service node switching information from user nodes into a consensus message through a master node in the blockchain network, and broadcast the consensus message to the blockchain network; A verification module, used to independently verify the consensus message through the replica nodes in the blockchain network, and when the verification passes, continue to forward it to other nodes; The voting module is used to vote through multiple consensus nodes. When more than a preset proportion of consensus nodes cast affirmative votes, a consensus is reached and the consensus message is added to the blockchain. The traceability module is used to trace the service node switching record of the target user by querying in the blockchain network.

7. The traceability system for service node switching based on blockchain according to claim 6 is characterized in that: The first base station is configured with a corresponding edge computing server as a user node, and the edge computing server is used for encapsulation and transaction broadcast of service node switching information.

8. The traceability system for service node switching based on blockchain according to claim 6 is characterized in that: The consensus message includes block information, digital signature and information summary.

9. The traceability system for service node switching based on blockchain according to claim 6 is characterized in that: The verification module is specifically used for: Determine, through the replica node in the blockchain network, whether the message type of the consensus message is the current execution stage; if so, proceed to the next step; Otherwise, the verification fails; Determine whether the view number of the consensus message is consistent with the current view number of the node; if so, proceed to the next step; Otherwise, the verification fails; Determine whether the sequence number of the consensus message is valid; If yes, go to the next step; Otherwise, the verification fails; Determine whether the timestamp of the consensus message is reasonable; If yes, go to the next step; Otherwise, the verification fails; Determine whether the digital signature of the consensus message is valid; if so, proceed to the next step; Otherwise, the verification fails; Get the private key corresponding to the public key ID, and use the private key to verify whether the signature in the message is consistent; if so, proceed to the next step; Otherwise, the verification fails; According to the digest algorithm, the digest of the consensus message is calculated, and the calculated digest is compared with the digest recorded in the consensus message to see if they are consistent; if so, the verification succeeds; otherwise, the verification fails.

10. The traceability system for service node switching based on blockchain according to claim 6 is characterized in that: The blockchain network adopts the PBFT consensus mechanism. When more than 2 / 3 of the consensus nodes cast affirmative votes, a consensus is reached and the consensus message is added to the blockchain.

Images