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

Abstract

This invention discloses a blockchain-based method and system for tracing service node switching, belonging to the field of communication technology. The method includes: constructing a blockchain network; when a user moves from the signal coverage area of ​​a first base station to the signal coverage area of ​​a second base station, recording service node switching information through the first base station; submitting the service node switching information to the blockchain network through the first base station as a user node; broadcasting a consensus message to the blockchain network through the master node; independently verifying the consensus message through replica nodes in the blockchain network, and forwarding it to other nodes when the verification is successful; reaching a consensus through voting by multiple consensus nodes, and adding the consensus message to the blockchain when more than a preset proportion of consensus nodes vote in favor; and tracing the service node switching record of the target user by querying the blockchain network.

Description

Technical Field

[0001] This invention belongs to the field of communication technology, specifically relating to a traceability method and system for service node switching based on blockchain. Background Technology

[0002] With the development of wireless communication, the number of users accessing 5G networks is increasing exponentially. At the same time, 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 handover records are generated in the network. This leads to problems with the reliability, consistency, integrity, security, and fault tolerance of faulty nodes in the handover records, thus making it impossible to guarantee the correctness of the traceability data.

[0003] Service node handover logs are crucial for network management and performance optimization. First, they provide a detailed record of the process and reasons for each handover. This is vital for network operators and regulatory bodies, helping them understand network operations, troubleshoot problems, and optimize network performance for more stable and efficient service. Second, these logs play a key role in fault diagnosis and recovery. When network failures occur, these logs help operators quickly pinpoint the root cause, reducing repair time and minimizing the impact of network outages on users. Most importantly, these handover logs involve data security and privacy protection. As critical network data, their security and integrity must be guaranteed to prevent data tampering, loss, or unauthorized access.

[0004] While some technologies, such as patents CN110677280A and CN114785531A, have solved the problem of establishing secure communication links between nodes, they overlook the lack of a decentralized consensus mechanism in traditional centralized network structures, potentially leading to inconsistencies in the consensus of handover records. Existing technologies also lack immutability and data sharing characteristics; data records stored in a single centralized database are vulnerable to attacks and single points of failure, thus compromising the security of handover records. Furthermore, existing technologies lack data traceability capabilities, making it impossible to fully understand the source and flow of handover for each service node. Summary of the Invention

[0005] To address the issues that existing technologies neglect the lack of decentralized consensus mechanisms in traditional centralized network structures, which may lead to inconsistent consensus on switchover records, and the lack of immutability and data sharing characteristics, as data records stored in a single centralized database are vulnerable to attacks and single points of failure, thus affecting the security of switchover records, and the lack of data traceability functions to fully understand the source and flow of each service node switchover, this invention provides a blockchain-based method and system for tracing the source of service node switchovers.

[0006] First aspect

[0007] This invention provides a traceability method for service node switching based on blockchain, comprising:

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

[0009] S2: When a user moves from the signal coverage area of ​​the first base station to the signal coverage area of ​​the second base station, the service node handover information is recorded through the first base station;

[0010] S3: By using the first base station as a user node in the blockchain network, the service node switching information is submitted to the blockchain network;

[0011] S4: Through the master node in the blockchain network, the multiple service node switching messages from the user nodes are encapsulated into a consensus message, and the consensus message is broadcast to the blockchain network;

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

[0013] S6: Through voting by multiple consensus nodes, when more than a preset proportion of consensus nodes cast their votes in favor, a consensus is reached, and the consensus message is added to the blockchain;

[0014] S7: By querying the blockchain network, the service node switching records of the target user are traced.

[0015] Furthermore, the first base station, as a user node, is configured with a corresponding edge computing server, which is used for encapsulating service node switching information and broadcasting transactions.

[0016] Furthermore, the consensus message includes block information, digital signature, and message digest.

[0017] Furthermore, S5 specifically includes:

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

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

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

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

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

[0023] 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 yes, proceed to the next step; otherwise, the verification fails.

[0024] 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; if they are consistent, the verification is successful; otherwise, the verification fails.

[0025] Furthermore, the blockchain network adopts the PBFT consensus mechanism. When more than 2 / 3 of the consensus nodes vote in agreement, a consensus is reached, and the consensus message is added to the blockchain.

[0026] Second aspect

[0027] This invention provides a traceability system for service node switching based on blockchain, comprising:

[0028] The building module is used to construct a blockchain network using base stations as distributed consensus nodes;

[0029] The recording module is used to record service node handover information through the first base station when a user moves from the signal coverage area of ​​the first base station to the signal coverage area of ​​the second base station.

[0030] The submission module is used 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;

[0031] The broadcast module is used to encapsulate multiple service node switching messages from user nodes into a consensus message through the master node in the blockchain network, and broadcast the consensus message to the blockchain network.

[0032] The verification module is used to independently verify the consensus message through the replica nodes in the blockchain network, and when the verification is successful, it continues to forward it to other nodes;

[0033] The voting module is used to vote through multiple consensus nodes. When more than a preset proportion of consensus nodes cast their votes in favor, a consensus is reached, and the consensus message is added to the blockchain.

[0034] The traceability module is used to trace the service node switching records of a target user by querying the blockchain network.

[0035] Furthermore, the first base station, as a user node, is configured with a corresponding edge computing server, which is used for encapsulating service node switching information and broadcasting transactions.

[0036] Furthermore, the consensus message includes block information, digital signature, and message digest.

[0037] Furthermore, the verification module is specifically used for:

[0038] The system uses replica nodes in the blockchain network to determine whether the message type of the consensus message corresponds to the current execution stage; if so, proceed to the next step; otherwise, the verification fails.

[0039] Determine whether the view number of the consensus message matches the current view number of the node; if yes, proceed to the next step; otherwise, verification fails.

[0040] Determine if the sequence number of the consensus message is valid; if yes, proceed to the next step; otherwise, verification fails.

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

[0042] Determine if the digital signature of the consensus message is valid; if yes, proceed to the next step; otherwise, verification fails.

[0043] Obtain the private key corresponding to the public key ID, and use the private key to verify whether the signature in the message matches; if yes, proceed to the next step; otherwise, the verification fails.

[0044] 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. If they are consistent, the verification is successful; otherwise, the verification fails.

[0045] Furthermore, the blockchain network adopts the PBFT consensus mechanism. When more than 2 / 3 of the consensus nodes vote in agreement, a consensus is reached, and the consensus message is added to the blockchain.

[0046] Compared with the prior art, the present invention has at least the following beneficial technical effects:

[0047] In this invention, the decentralized consensus mechanism and immutability of blockchain technology ensure that the service node switching information of a majority of nodes reaches a consensus, thereby enhancing the security, reliability, and transparency of the service node switching information. By querying the blockchain network, the service node switching records of a target user can be traced, enabling a comprehensive understanding of the source and flow of each service node switching. Attached Figure Description

[0048] The preferred embodiments will now be described in a clear and easy-to-understand manner, in conjunction with the accompanying drawings, to further explain the above-mentioned characteristics, technical features, advantages, and implementation methods of the present invention.

[0049] Figure 1 This is a flowchart illustrating a traceability method for service node switching based on blockchain provided by the present invention.

[0050] Figure 2 This is a timeline flowchart of a blockchain-based service node switching tracing method provided by the present invention.

[0051] Figure 3 This is a schematic diagram of the structure of a traceability system based on blockchain service node switching provided by the present invention. Detailed Implementation

[0052] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the specific implementation methods of the present invention will be described below with reference to the accompanying drawings. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings and other implementation methods can be obtained based on these drawings without any creative effort.

[0053] To keep the drawings concise, each figure only schematically shows the parts relevant to the invention, and these do not represent the actual structure of the product. Furthermore, to facilitate understanding, in some figures, only one of components with the same structure or function is schematically depicted, or only one is labeled. In this document, "one" not only means "only one," but can also mean "more than one."

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

[0055] In this document, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to fixed connections, detachable connections, or integral connections. They can refer to mechanical connections or electrical connections. They can refer to direct connections or indirect connections through an intermediate medium, or internal connections between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0056] Furthermore, in the description of this invention, the terms "first," "second," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0057] Example 1

[0058] In one embodiment, refer to the appendix to the specification. Figure 1 The diagram shows a flowchart of a blockchain-based traceability method for switching service nodes, provided by the present invention.

[0059] Reference manual attached Figure 2 The diagram shows a timing flowchart of a blockchain-based service node switching tracing method provided by the present invention.

[0060] This invention provides a traceability method for service node switching based on blockchain, comprising:

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

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

[0063] Base station equipment typically includes indoor and outdoor base stations, used to provide wide-area coverage and cell coverage. Base station equipment takes the form of communication devices and is usually installed at high locations or in specific areas to provide optimal wireless signal coverage.

[0064] Optionally, the base station is equipped with an edge computing server, which has both communication capabilities and certain computing and storage capabilities.

[0065] It should be noted that edge computing servers, using cloud computing technology, serve as computing devices for blockchain nodes. Installed near base stations, they enable edge computing functions and facilitate data encapsulation, consensus mechanisms, and on-chain processes for blockchain nodes. Edge computing servers can be dedicated servers or general-purpose server configurations.

[0066] Furthermore, the base station nodes form a decentralized blockchain network through peer-to-peer network connections. Edge computing servers connect to base station nodes via dedicated networks or local area networks to achieve data transmission and exchange.

[0067] Optionally, the blockchain network adopts the PBFT consensus mechanism based on consortium blockchains. This consensus mechanism has the characteristics of high decentralization, high throughput efficiency, and low consumption of computing resources, making it very suitable for operators to build blockchain networks.

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

[0069] Furthermore, in the PBFT consensus process, node roles will be divided into three types: user nodes, master nodes, and replica nodes.

[0070] In this context, the user node refers to the base station responsible for recording information and sending it to the master node during the consensus recording process of the service node switching.

[0071] 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 by the nodes of each view in turn to ensure the reliability and fairness of the system.

[0072] In this context, a replica node refers to any node in the blockchain consensus process other than the user node and the master node. The replica node is responsible for receiving messages from the master node and other replica nodes, and for verifying and processing those messages.

[0073] 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 basic architecture of the entire system. The following is a detailed explanation of these two layers:

[0074] For the wireless transport layer: This 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.

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

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

[0077] (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.

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

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

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

[0081] (2) Data encapsulation module: After the base station node generates a consensus request for a handover record, 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.

[0082] For the blockchain network layer: this mainly involves the blockchain's consensus algorithm, smart contracts, and data storage. These constitute the core of the distributed service node switching record.

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

[0084] Smart contracts: They automate and standardize operations such as adding and deleting nodes, help control the process of adding and leaving nodes, and provide a more transparent, secure, and trustworthy way to manage nodes, thereby enhancing the stability and reliability of the entire system.

[0085] 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-like structure and verified and added to through a consensus algorithm, ensuring data security and integrity.

[0086] S2: When a user moves from the signal coverage area of ​​the first base station to the signal coverage area of ​​the second base station, the service node handover information is recorded through the first base station.

[0087] In one possible implementation, the first base station is configured as a user node with a corresponding edge computing server, which is used for encapsulating service node switching information and broadcasting transactions.

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

[0089] In this invention, by recording service node handover information, the system can track the process of a user moving from one base station to another. This allows for a smoother service node handover when a user moves, thereby providing a better user experience and reducing the possibility of communication and service interruptions. Simultaneously, recording handover information facilitates effective resource management and load balancing. Operators can adjust the allocation of network resources based on the handover information, ensuring that each base station can effectively handle user traffic and preventing some base stations from becoming overloaded, thus avoiding a decline in service quality.

[0090] S3: By using the first base station as a user node in the blockchain network, the service node switching information is submitted to the blockchain network.

[0091] It should be noted that service node switching information is encoded into transactions, and user identities are encrypted to ensure data security and integrity. This transaction information, submitted by the user node via base station A using the PBFT consensus mechanism in the blockchain, is securely stored in an immutable blockchain and can be queried by authorized participants at any time. This information is used to trace user movement, optimize network performance, and meet regulatory and operational requirements. Simultaneously, to protect privacy, user identities are appropriately encrypted to ensure data security and integrity within the blockchain network.

[0092] Through these methods, service node switching information is securely stored in an immutable blockchain, which can be queried by authorized participants at any time. This information can be used to track user movement, optimize network performance, and meet regulatory and operational requirements. Meanwhile, to protect privacy, user identities can be appropriately encrypted, thereby ensuring data security and integrity.

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

[0094] The consensus message includes block information, digital signature, and message digest.

[0095] 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. Every once in a while, it retrieves multiple switching records from the information pool, encapsulates them into block data format, packages them into PBFT consensus messages, and then broadcasts them to the entire blockchain network.

[0096] 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 service node switching records, which are a collection of one or more service node switching records. Each record contains service node switching information such as service node information before the switch, service node information after the switch, and the switch time.

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

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

[0099] View: Represents the current view number. Each view corresponds to a master node, which is responsible for broadcasting pre-preparation 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.

[0100] Sequence Number: Represents the sequence number of the request in the current view. The master node ensures that requests are unique in each view and processed sequentially by incrementing the sequence number.

[0101] Digest: Represents the message's summary or hash value. In the PBFT algorithm, to reduce the amount of data transmitted over the network, nodes typically do not directly transmit the complete request message, but instead transmit a digest of the request message. The digest is calculated from the request content using a hash function and is used to verify the integrity and consistency of the information.

[0102] Message: Indicates the encapsulated block information of the service node switching record.

[0103] BasestationID: Represents the base station ID that initiated the request for this message. In a distributed system, multiple user nodes may simultaneously send consensus requests to the system. Using BasestationID can distinguish the base station that initiated the consensus request, ensuring that each base station's request is processed correctly.

[0104] Timestamp: Represents the timestamp of the broadcast message. The PBFT algorithm requires all nodes to process requests in the same order, therefore the timestamp is used to determine the order of requests.

[0105] Signature: Represents the digital signature of a blockchain node. When a node sends a request, it uses its private key to sign the request data. Other nodes, upon receiving the request, use their respective public keys to verify the signature, ensuring the request's legitimacy.

[0106] S5: Consensus messages are independently verified by replica nodes in the blockchain network. When the verification is successful, the messages are forwarded to other nodes.

[0107] 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 transaction's legality and the validity of the digital signature. Then, the node forwards the transaction to other nodes.

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

[0109] S501: Determine whether the message type of the consensus message matches the current execution stage by checking the replica nodes in the blockchain network. If yes, proceed to the next step. Otherwise, verification fails.

[0110] S502: Determine if the view number of the consensus message matches the node's current view number. If yes, proceed to the next step. Otherwise, verification fails.

[0111] S503: Determine if the sequence number of the consensus message is valid. If yes, proceed to the next step. Otherwise, verification fails.

[0112] S504: Determine if the timestamp of the consensus message is valid. If yes, proceed to the next step. Otherwise, verification fails.

[0113] S505: Determine if the digital signature of the consensus message is valid. If yes, proceed to the next step. Otherwise, verification fails.

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

[0115] 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. If they match, the verification is successful. Otherwise, the verification fails.

[0116] In this invention, by verifying the message type, view number, sequence number, timestamp, digital signature, and digest, erroneous or fraudulent messages can be prevented from being mistakenly propagated into the blockchain network. This helps maintain the consistency and accuracy of the network.

[0117] S6: Through voting by multiple consensus nodes, when more than a preset proportion of consensus nodes cast their votes in favor, a consensus is reached, and the consensus message is added to the blockchain.

[0118] In one possible implementation, the blockchain network uses the PBFT consensus mechanism, where consensus is reached when more than 2 / 3 of the consensus nodes vote in favor, and the consensus message is added to the blockchain.

[0119] Specifically, the PBFT consensus mechanism is divided into a pre-preparation phase, a preparation phase, a commit phase, and a response phase. Each node broadcasts pre-preparation, preparation, commit, and response messages to other nodes in the corresponding phases to reach consensus. After receiving and verifying sufficient pre-preparation and preparation messages, nodes vote on transactions to achieve consensus. When more than two-thirds of the nodes agree that the transaction is valid, consensus is reached, a new block is added to the blockchain, the record is confirmed and uploaded to the chain, and finally, the base station stores the consensus information containing the service switch record in its respective computing server's database.

[0120] The PBFT consensus mechanism effectively achieves fault tolerance for failed nodes. This is because the PBFT algorithm allows nodes to tolerate up to one-third of the total number of failed nodes in the network while still maintaining normal system operation and consensus. This is achieved through multiple rounds of consensus message broadcasting, voting, verification, consensus, and the majority rule principle among nodes. When nodes need to reach consensus, they communicate and vote with each other. Only when a sufficient number of nodes reach agreement will a transaction or decision be confirmed as valid. This approach effectively resists potential malicious behavior and problems caused by failed nodes, providing a certain degree of fault tolerance for distributed systems, ensuring the overall normal operation of the system even when some nodes fail.

[0121] In this invention, the PBFT consensus algorithm is employed to ensure that nodes in the blockchain reach a consensus on service switching records, preventing faulty or malicious nodes from corrupting the records, improving consensus efficiency, and ensuring the security and stability of the blockchain network. Furthermore, considering the large number of 5G service users and high throughput demands, the fact that base stations are provided by operators as nodes, and the limited computing resources of edge computing servers, special attention is paid to node fault tolerance to ensure that even when some nodes fail or are attacked, the entire network can still achieve correct consensus and maintain the stability of service node switching records.

[0122] S7: By querying the blockchain network, the service node switching records of the target user can be traced.

[0123] Specifically, because switchover records are stored on the blockchain, any node can trace and verify them. Users or network administrators can use blockchain explorers or custom query tools to find the switchover records of a specific user, including the source, destination, and related user information.

[0124] This invention combines data traceability with existing blockchain technology, enabling data traceability and verification through smart contracts. A permission management mechanism is introduced to authorize user access to functions. Security auditing and monitoring mechanisms are also incorporated to record and monitor the operation of the data traceability function. This integration is novel and non-obvious, giving blockchain technology broader application prospects in the field of data traceability.

[0125] Compared with the prior art, the present invention has at least the following beneficial technical effects:

[0126] In this invention, the decentralized consensus mechanism and immutability of blockchain technology ensure that the service node switching information of a majority of nodes reaches a consensus, enhancing the security, reliability, and transparency of service node switching information. By querying the blockchain network, the service node switching records of a target user can be traced, enabling a comprehensive understanding of the source and flow of each service node switching.

[0127] Example 2

[0128] In one embodiment, refer to the appendix to the specification. Figure 3 The diagram shows a schematic representation of the traceability system based on blockchain service node switching provided by the present invention.

[0129] This invention provides a traceability system for service node switching based on blockchain, comprising:

[0130] Module 301 is used to build a blockchain network using base stations as distributed consensus nodes;

[0131] The recording module 302 is used to record service node handover information through the first base station when a user moves from the signal coverage area of ​​the first base station to the signal coverage area of ​​the second base station;

[0132] The submission module 303 is used to submit the service node switching information to the blockchain network through the first base station as a user node in the blockchain network;

[0133] The broadcast module 304 is used to encapsulate multiple service node switching messages from user nodes into a consensus message through the master node in the blockchain network, and broadcast the consensus message to the blockchain network.

[0134] The verification module 305 is used to independently verify the consensus message through the replica nodes in the blockchain network, and when the verification is successful, it continues to forward it to other nodes;

[0135] The voting module 306 is used to vote through multiple consensus nodes. When more than a preset proportion of consensus nodes cast their votes in agreement, a consensus is reached, and the consensus message is added to the blockchain.

[0136] The traceability module 307 is used to trace the service node switching records of a target user by querying the blockchain network.

[0137] In one possible implementation, the first base station is configured as a user node with a corresponding edge computing server, which is used for encapsulating service node switching information and broadcasting transactions.

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

[0139] In one possible implementation, the verification module 305 is specifically used for:

[0140] The system uses replica nodes in the blockchain network to determine whether the message type of the consensus message corresponds to the current execution stage; if so, proceed to the next step; otherwise, the verification fails.

[0141] Determine whether the view number of the consensus message matches the current view number of the node; if yes, proceed to the next step; otherwise, verification fails.

[0142] Determine if the sequence number of the consensus message is valid; if yes, proceed to the next step; otherwise, verification fails.

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

[0144] Determine if the digital signature of the consensus message is valid; if yes, proceed to the next step; otherwise, verification fails.

[0145] Obtain the private key corresponding to the public key ID, and use the private key to verify whether the signature in the message matches; if yes, proceed to the next step; otherwise, the verification fails.

[0146] 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. If they are consistent, the verification is successful; otherwise, the verification fails.

[0147] In one possible implementation, the blockchain network employs the PBFT consensus mechanism, where consensus is reached when more than two-thirds of the consensus nodes vote in favor, and the consensus message is added to the blockchain.

[0148] The traceability system for service node switching based on blockchain provided by this invention can realize the steps and effects of the traceability method for service node switching based on blockchain in Embodiment 1 above. To avoid repetition, this invention will not repeat them.

[0149] Compared with the prior art, the present invention has at least the following beneficial technical effects:

[0150] In this invention, the decentralized consensus mechanism and immutability of blockchain technology ensure that the service node switching information of a majority of nodes reaches a consensus, thereby enhancing the security, reliability, and transparency of the service node switching information. By querying the blockchain network, the service node switching records of a target user can be traced, enabling a comprehensive understanding of the source and flow of each service node switching.

[0151] The technical features of the above embodiments can be combined in any way. For the sake of brevity, 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.

[0152] The above embodiments merely illustrate several implementation methods of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this invention patent should be determined by the appended claims.

Claims

1. A traceability method for service node switching based on blockchain, characterized in that, include: S1: Using base stations as distributed consensus nodes to build a blockchain network; S2: When a user moves from the signal coverage area of ​​the first base station to the signal coverage area of ​​the second base station, the service node handover information is recorded through the first base station; S3: By using the first base station as a user node in the blockchain network, the service node switching information is submitted to the blockchain network; S4: Through the master node in the blockchain network, the multiple service node switching messages from the user nodes are encapsulated into a consensus message, and the consensus message is broadcast to the blockchain network; S5: The consensus message is independently verified by the replica nodes in the blockchain network. When the verification is successful, it is forwarded to other nodes. S6: Through voting by multiple consensus nodes, when more than a preset proportion of consensus nodes cast their votes in favor, a consensus is reached, and the consensus message is added to the blockchain; S7: By querying the blockchain network, the service node switching records of the target user are traced. The data format of the consensus message is as follows:<Type,View,Sequence Number,Digest, Message,Basestation ID,Timestamp,Signature> ; Wherein, Type represents the message type, View represents the current view number, Sequence Number represents the sequence number of the request in the current view, Digest represents the message digest, Message represents the block information encapsulated after the service node switching record is completed, Basestation ID represents the base station ID that initiated the message request, Timestamp represents the timestamp of broadcasting the message, and Signature represents the digital signature of the blockchain node. Specifically, S5 includes: S501: Determine whether the message type of the consensus message is the current execution stage through the replica nodes in the blockchain network; if yes, proceed to the next step; otherwise, verification fails. S502: Determine whether the view number of the consensus message is consistent with the current view number of the node; if yes, proceed to the next step; otherwise, verification fails. S503: Determine whether the sequence number of the consensus message is valid; if yes, proceed to the next step; otherwise, verification fails. S504: Determine whether the timestamp of the consensus message is reasonable; if yes, proceed to the next step; otherwise, verification fails. S505: Determine whether the digital signature of the consensus message is valid; if yes, proceed to the next step; otherwise, 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 yes, 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; if they are consistent, the verification is successful; otherwise, the verification fails.

2. The traceability method for service node switching based on blockchain according to claim 1, characterized in that, The first base station is configured with a corresponding edge computing server as a user node. The edge computing server is used for encapsulating service node switching information and broadcasting transactions.

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

4. The traceability method for service node switching based on blockchain according to claim 1, characterized in that, The blockchain network adopts the PBFT consensus mechanism. When more than 2 / 3 of the consensus nodes vote in favor, a consensus is reached and the consensus message is added to the blockchain.

5. A traceability system for service node switching based on blockchain, characterized in that, include: The building module is used to construct a blockchain network using base stations as distributed consensus nodes; The recording module is used to record service node handover information through the first base station when a user moves from the signal coverage area of ​​the first base station to the signal coverage area of ​​the second base station. The submission module is used 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; The broadcast module is used to encapsulate multiple service node switching messages from user nodes into a consensus message through the master node in the blockchain network, and broadcast the consensus message to the blockchain network. The verification module is used to independently verify the consensus message through the replica nodes in the blockchain network, and when the verification is successful, it continues 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 their votes in favor, a consensus is reached, and the consensus message is added to the blockchain. The traceability module is used to trace the service node switching records of a target user by querying the blockchain network. The data format of the consensus message is as follows:<Type,View,Sequence Number,Digest, Message,Basestation ID,Timestamp,Signature> ; Wherein, Type represents the message type, View represents the current view number, Sequence Number represents the sequence number of the request in the current view, Digest represents the message digest, Message represents the block information encapsulated after the service node switching record is completed, Basestation ID represents the base station ID that initiated the message request, Timestamp represents the timestamp of broadcasting the message, and Signature represents the digital signature of the blockchain node. Specifically, the verification module is used for: The system uses replica nodes in the blockchain network to determine whether the message type of the consensus message corresponds to the current execution stage; if so, proceed to the next step; otherwise, the verification fails. Determine whether the view number of the consensus message matches the current view number of the node; if yes, proceed to the next step; otherwise, the verification fails. Determine if the sequence number of the consensus message is valid; if yes, proceed to the next step; otherwise, verification fails. Determine if the timestamp of the consensus message is reasonable; if so, proceed to the next step; otherwise, verification fails. Determine if the digital signature of the consensus message is valid; if yes, proceed to the next step; otherwise, verification fails. Obtain the private key corresponding to the public key ID, and use the private key to verify whether the signature in the message matches; if yes, 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. If they are consistent, the verification is successful; otherwise, the verification fails.

6. The traceability system for service node switching based on blockchain according to claim 5, characterized in that, The first base station is configured with a corresponding edge computing server as a user node. The edge computing server is used for encapsulating service node switching information and broadcasting transactions.

7. The traceability system for service node switching based on blockchain according to claim 5, characterized in that, The consensus message includes block information, digital signature, and message digest.

8. The traceability system for service node switching based on blockchain according to claim 5, characterized in that, The blockchain network adopts the PBFT consensus mechanism. When more than 2 / 3 of the consensus nodes vote in favor, a consensus is reached and the consensus message is added to the blockchain.

Images