Internet of vehicles block chain expansibility and performance optimization method based on fragmentation technology

Abstract

The invention relates to an Internet of Vehicles block chain expansibility and performance optimization method based on a fragmentation technology, and belongs to the field of block chains. The method comprises the following steps: 1) constructing a root chain network and fragmentation network structure, and carrying out fragmentation design; 2) performing single fragment transaction processing by using a flexible consensus mechanism; 3) performing cross-fragment transaction processing by using coordination among multiple fragments; 4) the storage overhead is reduced by using state fragmentation and account book cutting; and 5) dynamically adjusting computing power distribution of the root chain and the fragments by using a market incentive mechanism. According to the method, the delay and throughput problems of the block chain are researched in the Internet of Vehicles environment, and the expansibility and performance of the block chain system can be effectively improved.

Description

Technical Field

[0001] The present invention belongs to the field of Internet of Vehicles and blockchain, and relates to an Internet of Vehicles blockchain scalability and performance optimization method based on sharding technology. Background Art

[0002] With the rapid development of Internet of Vehicles (IoV) technology, the interconnection between vehicles and road infrastructure, cloud platforms, etc. is becoming increasingly close, and IoV has become an important part of the intelligent transportation system. However, the widespread application of IoV has also brought about the generation of a large amount of data, requiring efficient, secure and low-latency processing and storage of data. The traditional centralized architecture is difficult to meet the requirements of high dynamics, high concurrency and high security in the IoV environment, especially in terms of data credibility, computing bottlenecks and single point failures.

[0003] As a decentralized, transparent and trusted distributed ledger technology, blockchain technology offers the potential to ensure data security, improve transparency and promote multi-party collaboration in the Internet of Vehicles. The advantages of blockchain’s immutability and data consistency make it an ideal solution for Internet of Vehicles data management and transaction security. However, existing blockchain systems show performance bottlenecks when faced with the high dynamics and heterogeneity of the Internet of Vehicles. In particular, as the node scale expands and the transaction frequency increases, traditional blockchain public chain systems (such as Bitcoin and Ethereum) often face problems such as reduced throughput and increased transaction confirmation delays, which limits their application in the Internet of Vehicles.

[0004] In order to break through these bottlenecks, sharding technology has received widespread attention as a key technology for optimizing blockchain performance. Sharding technology significantly improves the system's throughput and scalability by dividing the blockchain network into multiple independent shards, each of which processes transactions in parallel. However, existing sharding technologies still face many challenges in the application of the Internet of Vehicles. First, fixed sharding schemes are difficult to cope with dynamic changes in the Internet of Vehicles environment, such as frequent vehicles entering and leaving the network or fluctuations in network quality. In addition, existing sharding technologies have deficiencies in cross-shard communication efficiency and security, which may lead to a decrease in transaction performance between shards, and even cause problems such as data inconsistency or double-spending attacks. Therefore, it is necessary to study blockchain sharding methods that are more suitable for the Internet of Vehicles environment in terms of adapting to dynamic network environments, improving system throughput, reducing transaction delays, and improving scalability. Summary of the invention

[0005] In view of this, the purpose of the present invention is to provide a method for optimizing the scalability and performance of the Internet of Vehicles blockchain based on sharding technology.

[0006] In order to achieve the above object, the present invention provides the following technical solutions:

[0007] A method for optimizing the scalability and performance of a blockchain for Internet of Vehicles based on sharding technology, comprising the following steps:

[0008] Step 1: Build the root chain network and sharding network structure, and perform sharding design;

[0009] Step 2: Use flexible consensus mechanism to process single-shard transactions;

[0010] Step 3: Use coordination between multiple shards to process cross-shard transactions;

[0011] Step 4: Use state sharding and ledger pruning to reduce storage overhead;

[0012] Step 5: Use market incentives to dynamically adjust the computing power distribution of the root chain and shards;

[0013] Optionally, the specific process of step 1 includes: We design a two-layer architecture consisting of a root chain network and a shard network. The root chain network is responsible for overall security and cross-shard transaction verification, and maintains the global ledger; the shard network processes transactions in parallel on multiple independent shards, and each shard maintains its own ledger to share the storage and computing burden.

[0014] We set up transaction sharding to process transactions in parallel through sharding, thereby improving transaction throughput and scalability. Transactions are assigned to specific shards, and the target shard is specified based on the input address (source address) of the transaction. That is, the address is formed into a "composite address" by concatenating the block address and the shard ID. And according to the distribution of the input and output addresses of the transaction, the transactions are divided into the following three categories: (1) the input and output addresses are both in the same shard (single-shard transaction); (2) the input address is in the same shard, but the output address is distributed in different shards (special single-shard transaction); (3) the input and output addresses are distributed in different shards (cross-shard transaction). Among them, the inputs of single-shard transactions and special single-shard transactions are in the same shard, so they can be fully verified in a single shard. The shard network consists of multiple shards, each of which is responsible for maintaining disjoint transaction ledgers and processing a set of disjoint transactions. Transactions are routed to the corresponding shards based on their input addresses. Nodes in the same shard collect transactions within the shard into shard blocks and run flexible consensus to attach shard blocks to their own chains. Cross-shard transactions are split into intra-shard transactions or processed by the root chain network.

[0015] Optionally, in step 2, single-shard transactions can be fully verified within the shard without communicating with other shards. We use the idea of ​​flexible arbitration sets to weaken the requirement that "all arbitration sets must intersect" to "only arbitration sets in different stages need to intersect." Therefore, it is only necessary to ensure that the arbitration set (Q1) of the first stage intersects with the arbitration set (Q2) of the second stage, allowing performance to be improved by adjusting the size of Q1 and Q2. Assuming that failures and the resulting leader changes are rare, the second stage (the stage in which the leader instructs the recipient to decide the value) runs more frequently than the first stage (the new leader election stage). Therefore, the performance of the protocol can be optimized by reducing the size of Q2 (improving the efficiency of the second stage) while increasing the size of the less used Q1. If the arbitration set on the node set is secure, then the arbitration sets used in the first and second stages should be intersecting. That is,

[0016] We define the tolerable number of regional failures f z and the number of node failures f that a region can tolerate before losing availability n In order to tolerate f in each region n Crash failure, we choose any f in the area n +1 node. In addition, in order to tolerate f in Z regions z Secondary fault, Q1 in Q1 from Zf z Select from the regions, q2 in Q2 from f z +1 region to choose from. Based on the above assumptions, the arbitration set is defined as follows:

[0017]

[0018] Where SUBSET q represents a subset of q, and Cardinality(q) represents the number of elements in set q. We define F min is the size of the fault set F under the worst-case fault distribution, i.e., the minimum number of faults that violate the availability of read / write operations for any item. If all faults are concentrated on a particular q∈Q2, then q∈Q2 will be completely unavailable after Cardinality(Q2) faults. By definition, any Q2 arbitration set intersects with any Q1 arbitration set. When a Q2 arbitration set is completely cleared, the failure that occurs will make any Q1 arbitration set unavailable as well. F min The formula is as follows:

[0019] F min =Min(Cardinality(Q2),Cardinality(Q1))-1

[0020] We define F maxis the size of the fault set F in the best case of fault distribution in the grid. In this case, the fault misses the union of the Q1 quorum set and the Q2 quorum set, leaving at least one Q1 quorum set and one Q2 quorum set intact. F max The formula is as follows:

[0021] F max =N-Cardinality(Q1)-Cardinality(Q2)+(f z +1)*(f n +1)

[0022] Based on this, a multi-leader protocol based on flexible arbitration sets is proposed, that is, each node in the system can serve as a leader for a part of the objects. The multi-leader protocol based on flexible arbitration sets consists of two phases. In the first phase, phase 1 of multiple concurrent leaders is executed on q1∈Q1, stealing the ownership / leadership of the object from each other. In the second phase, the leader submits an update request to the object, and when executing phase 2, the selected q2∈Q2 comes from the area where the leader is located (and nearby areas) to improve locality. The leader can execute the second phase multiple times until other nodes steal the object.

[0023] Phase 1 of the protocol is executed only when a node needs to steal an object from a remote leader, or when a client requests a new object that does not exist in the system. This phase causes the election number of the object involved to increase. Once a node becomes the owner / leader of an object, it executes phase 2 multiple times on that object to submit commands / updates, incrementing the slot number at each iteration, while the object's election number remains unchanged.

[0024] When a node needs to steal an object from another leader to process a client request, it first consults its internal cache to determine the last ballot number used on the object and performs a phase one operation on some q1∈Q1 with a higher ballot number. If the candidate node is able to surpass the current leader's ballot number, the object stealing succeeds. Once the object is stolen, the old leader can no longer operate on the object because the object is now associated with a higher ballot number than the old leader's ballot number. This rule holds true even if the old leader was not in q1 when the object was stolen. Object stealing can occur while some commands have not yet completed, so the new leader must revert any object commands that have been accepted but not yet committed.

[0025] We maintain a separate ballot number for each object, isolating the impact of object theft. This will also lead to the problem of leader duels, where two nodes steal different objects from each other by continuously proposing higher ballot numbers than each other. To solve this problem, we take two additional protective measures: (1) in the case of the same ballot number, the ballot conflict is resolved by region ID and node ID, and (2) if a new duel iteration is still started, a random backoff mechanism is adopted.

[0026] Nodes within the shard generate blocks through a flexible consensus mechanism and add transactions to the blockchain. The root chain network then verifies the legitimacy of the shard block and generates a root block, ultimately confirming the transaction.

[0027] Optionally, in step 3, for cross-shard transactions, the cross-shard communication overhead directly affects the efficiency of cross-shard transaction processing and the communication burden of the entire system. Because the root chain maintains the entire ledger and does not need to communicate with other shards, we assign cross-shard transactions to the root chain network to eliminate cross-shard communication. Therefore, we reduce the number of cross-shard transactions by the following two methods. First, since we assign transactions to shards based on the input addresses of the transactions, we can encourage users to generate new addresses belonging to the same shard so that users can perform as many intra-shard transactions as possible, thereby obtaining fast confirmation and paying less transaction fees. Second, in most cases, it is not necessary to maintain the atomicity of transactions. Therefore, the number of cross-shard transactions can be further reduced by splitting cross-shard transactions into several intra-shard transactions. For example, a transaction TX:In(A+B)→Out(C) can be split into TX1:In(A)→Out(C) and TX2:In(B)→Out(C). This split operation can be performed automatically by the node. Under this strategy, the number of cross-shard transactions can be effectively controlled. Finally, a small number of cross-shard transactions that must remain atomic can be processed through the root chain network.

[0028] Optionally, in step 4, the entire address space is logically divided into multiple disjoint parts, and each shard is only responsible for maintaining the ledger of its own shard, rather than the complete blockchain, which can reduce the storage burden of the shard nodes. State sharding faces the challenge of data availability. Since the state of the system is not replicated between all shards, the network can no longer verify transactions that depend on the attacked shard. Therefore, let the nodes in the root chain network store the entire ledger, including the root block and all shard blocks. A block may contain some outputs pointing to other shards. If each shard needs to check all transactions in each block, it will consume a lot of time and resources. Therefore, we introduce a Bloom filter structure in the block header to indicate which shards the output will be sent to. The node only needs to check the Bloom filter to determine whether there is a related output. In our two-layer structure, since the root chain network is responsible for maintaining the security of the system, nodes can freely join one or more shards without reshuffling the network, thus avoiding the overhead of data migration.

[0029] At the same time, in order to reduce the storage cost of the root chain and shards, checkpoints are introduced to summarize the entire state of the blockchain. Create a checkpoint cp for shard i in block segment e i,e The nodes of the shard execute the following steps: At the end of the block segment e (determined by the block height, for example, every 2048 blocks is considered a block segment), the node stores the UTXO in a sorted Merkle tree and puts the root hash of the Merkle tree into the head of the checkpoint. Since each node can build the same ordered Merkle tree, the checkpoint can be verified by each node. Afterwards, if the checkpoint is confirmed by the entire network, the checkpoint cp can be safely discarded i,e Previous block data.

[0030] Optionally, in step 5, we introduce a market incentive mechanism to dynamically adjust the computing power distribution between shards and the root chain. Under the incentive mechanism, nodes tend to choose shards with lower loads, balancing the computing power and transaction processing capabilities between shards, thereby avoiding regular reshuffles of the network. is a security parameter, HashPower(m) represents the total hash power of malicious nodes, HashPower(w) represents the hash power of the entire network, and represents the proportion of Byzantine nodes that the system can tolerate. Then the definition of Θ is as follows:

[0031]

[0032] To ensure that the root chain occupies most of the network's computing power (e.g. >50%), it is difficult for malicious nodes to launch attacks. Therefore, the total hash power of the root chain HashPower(r) is:

[0033]

[0034] Then for the total hash power of the root chain HashPower(r), we have:

[0035] HashPower(r)>2·Θ·HashPower(w)

[0036] At the same time, the computing power is evenly distributed among the shards so that each shard can work normally. Let HashPower(s) represent the computing power of each shard, and N represents the number of shards, then:

[0037]

[0038] We assume that most nodes are rational, that is, they are driven by their own interests and choose to work in the shard with the richest rewards. To achieve this goal, the block reward should be designed reasonably to ensure that the same computing power can get the same reward no matter which shard it works on. Let BlockReward(r) and BlockReward(s) represent the reward obtained for generating a block on the root chain and the block respectively. BlockInterval(r) and BlockInterval(s) represent the average time interval for generating new blocks on the root chain and the shard respectively. Therefore, the block rewards of the root chain and the shard should satisfy the following formula:

[0039]

[0040] When a new node joins the network, it will try to find the most profitable shard. The new node will first calculate the per-hash revenue G of all shards and select the shard with the highest revenue. Let P be the current hash power, then the per-hash revenue G is defined as follows:

[0041]

[0042] The beneficial effects of the present invention are as follows: the present invention proposes a method for optimizing the scalability and performance of the Internet of Vehicles blockchain based on sharding technology, including: 1) constructing a two-layer structure consisting of a root chain network and a sharding network; 2) utilizing a flexible consensus mechanism to efficiently process transactions within and between shards; 3) reducing storage overhead based on state sharding and ledger pruning; 4) dynamically adjusting the computing power distribution of the root chain and shards through a market incentive mechanism.

[0043] Other advantages, objectives and features of the present invention will be described in the following description to some extent, and to some extent, will be obvious to those skilled in the art based on the following examination and study, or can be taught from the practice of the present invention. The objectives and other advantages of the present invention can be realized and obtained through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] In order to make the purpose, technical solutions and advantages of the present invention more clear, the present invention will be described in detail below in conjunction with the accompanying drawings, wherein:

[0045] Figure 1 A flowchart of the scalability and performance optimization method of the Internet of Vehicles blockchain based on sharding technology;

[0046] Figure 2 This is a diagram of the blockchain sharding structure. DETAILED DESCRIPTION

[0047] The following describes the embodiments of the present invention by specific examples, and those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the illustrations provided in the following embodiments only illustrate the basic concept of the present invention in a schematic manner, and the following embodiments and features in the embodiments can be combined with each other without conflict.

[0048] Among them, the drawings are only used for illustrative explanations, and they only represent schematic diagrams rather than actual pictures, and should not be understood as limitations on the present invention. In order to better illustrate the embodiments of the present invention, some parts of the drawings may be omitted, enlarged or reduced, and do not represent the size of actual products. For those skilled in the art, it is understandable that some well-known structures and their descriptions in the drawings may be omitted.

[0049] The same or similar numbers in the drawings of the embodiments of the present invention correspond to the same or similar parts; in the description of the present invention, it should be understood that if the terms "upper", "lower", "left", "right", "front", "rear", etc. indicate the orientation or position relationship, they are based on the orientation or position relationship shown in the drawings, which is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operate in a specific orientation. Therefore, the terms describing the position relationship in the drawings are only used for illustrative purposes and cannot be understood as limiting the present invention. For ordinary technicians in this field, the specific meanings of the above terms can be understood according to specific circumstances.

[0050] See also Figure 1-2 The present invention provides a method for optimizing the scalability and performance of Internet of Vehicles blockchain based on sharding technology. Figure 1 The following is a flowchart for the specific implementation.

[0051] Figure 2 This is a full-sharding structure diagram of the blockchain public chain of the present invention. The following is an explanation with reference to the accompanying drawings, including the following steps:

[0052] Optionally, the specific process of step 1 includes: We design a two-layer architecture consisting of a root chain network and a shard network. The root chain network is responsible for overall security and cross-shard transaction verification, and maintains the global ledger; the shard network processes transactions in parallel on multiple independent shards, and each shard maintains its own ledger to share the storage and computing burden.

[0053] We set up transaction sharding to process transactions in parallel through sharding, thereby improving transaction throughput and scalability. Transactions are assigned to specific shards, and the target shard is specified based on the input address of the transaction. That is, the address is formed into a "composite address" by concatenating the block address and the shard ID. According to the distribution of the input and output addresses of the transaction, transactions are divided into the following three categories: (1) the input and output addresses are both in the same shard (single-shard transaction); (2) the input address is in the same shard, but the output addresses are distributed in different shards (special single-shard transaction); (3) the input and output addresses are distributed in different shards (cross-shard transaction). Among them, the inputs of single-shard transactions and special single-shard transactions are in the same shard, so they can be fully verified in a single shard. The sharding network consists of multiple shards, each of which is responsible for maintaining disjoint transaction ledgers and processing a set of disjoint transactions.

[0054] Optionally, in step 2, we use the idea of ​​flexible arbitration sets to weaken the requirement of "all arbitration sets must intersect" to "only arbitration sets in different stages need to intersect". Therefore, it is only necessary to ensure that the arbitration set (Q1) of the first stage intersects with the arbitration set (Q2) of the second stage, allowing performance to be improved by adjusting the size of Q1 and Q2. The performance of the protocol can be optimized by reducing the size of Q2 (improving the efficiency of the second stage) while increasing the size of the less used Q1. If the arbitration set on the node set is safe, then the arbitration sets used in the first and second stages should be intersecting. That is,

[0055] We define the tolerable number of regional failures f z and the number of node failures f that a region can tolerate before losing availability n In order to tolerate f in each region n Crash failure, we choose any f in the area n +1 node. In addition, in order to tolerate f in Z regions z Secondary fault, Q1 in Q1 from Zf z Select from the regions, q2 in Q2 from f z +1 region to choose from. Based on the above assumptions, the arbitration set is defined as follows:

[0056]

[0057] Where SUBSET q represents a subset of q, and Cardinality(q) represents the number of elements in set q. We define F min is the size of the fault set F under the worst fault distribution, that is, the minimum number of faults that violate the availability of read / write operations for any item. If all faults are concentrated on a specific q∈Q2, then q∈Q2 will be completely ineffective after Cardinality(Q2) faults occur. F min The formula is as follows:

[0058] F min =Min(Cardinality(Q2),Cardinality(Q1))-1

[0059] We define F max is the size of the fault set F in the best case of fault distribution in the grid. In this case, the fault misses the union of the Q1 quorum set and the Q2 quorum set, leaving at least one Q1 quorum set and one Q2 quorum set intact. F max The formula is as follows:

[0060] F max =N-Cardinality(Q1)-Cardinality(Q2)+(f z +1)*(f n +1)

[0061] Based on this, a multi-leader protocol based on flexible arbitration sets is proposed, that is, each node in the system can serve as a leader for a part of the objects. The multi-leader protocol based on flexible arbitration sets consists of two phases. In the first phase, phase 1 of multiple concurrent leaders is executed on q1∈Q1, stealing the ownership / leadership of the object from each other. In the second phase, the leader submits an update request to the object. When executing phase 2, the selected q2∈Q2 comes from the area where the leader is located (and nearby areas) to improve locality. The leader can execute the second phase multiple times until other nodes steal the object.

[0062] Phase 1 of the protocol is executed only when a node needs to steal an object from a remote leader, or when a client requests a new object that does not exist in the system. This phase causes the election number of the object involved to increase. Once a node becomes the owner / leader of an object, it executes phase 2 multiple times on that object to submit commands / updates, incrementing the slot number at each iteration, while the object's election number remains unchanged.

[0063] When a node needs to steal an object from another leader to process a client request, it first consults its internal cache to determine the last ballot number used on the object and performs a phase one operation on some q1∈Q1 with a higher ballot number. If the candidate node is able to surpass the current leader's ballot number, the object stealing succeeds. Once the object is stolen, the old leader can no longer operate on the object because the object is now associated with a higher ballot number than the old leader's ballot number. This rule holds true even if the old leader was not in q1 when the object was stolen. Object stealing can occur while some commands have not yet completed, so the new leader must revert any object commands that have been accepted but not yet committed.

[0064] We maintain independent ballot numbers for each object, thus isolating the impact of object theft. This will also lead to the problem of leader duel, where two nodes steal different objects from each other by continuously proposing higher ballot numbers than each other. To solve this problem, we take two additional protective measures: (1) in the case of the same ballot number, the ballot conflict is resolved by the region ID and node ID, and (2) if a new duel iteration is still started, a random backoff mechanism is adopted. Nodes within the shard generate blocks through a flexible consensus mechanism and add transactions to the blockchain. Then the root chain network verifies the legitimacy of the shard block and generates a root block, which finally confirms the transaction.

[0065] Optionally, in step 3, for cross-shard transactions, the cross-shard communication overhead directly affects the efficiency of cross-shard transaction processing and the communication burden of the entire system. Because the root chain maintains the entire ledger and does not need to communicate with other shards, we assign cross-shard transactions to the root chain network to eliminate cross-shard communication. Therefore, we reduce the number of cross-shard transactions by the following two methods. First, since we assign transactions to shards based on the input addresses of the transactions, we can encourage users to generate new addresses belonging to the same shard so that users can perform as many intra-shard transactions as possible, thereby obtaining fast confirmation and paying less transaction fees. Second, in most cases, it is not necessary to maintain the atomicity of transactions. Therefore, the number of cross-shard transactions can be further reduced by splitting cross-shard transactions into several intra-shard transactions. For example, a transaction TX:In(A+B)→Out(C) can be split into TX1:In(A)→Out(C) and TX2:In(B)→Out(C). This split operation can be performed automatically by the node. Under this strategy, the number of cross-shard transactions can be effectively controlled. Finally, a small number of cross-shard transactions that must remain atomic can be processed through the root chain network.

[0066] Optionally, in step 4, the entire address space is logically divided into multiple disjoint parts, and each shard is only responsible for maintaining the ledger of its own shard, rather than the complete blockchain, which can reduce the storage burden of the shard nodes. State sharding faces the challenge of data availability. Since the state of the system is not replicated between all shards, the network can no longer verify transactions that depend on the attacked shard. Therefore, let the nodes in the root chain network store the entire ledger, including the root block and all shard blocks. A block may contain some outputs pointing to other shards. If each shard needs to check all transactions in each block, it will consume a lot of time and resources. Therefore, we introduce a Bloom filter structure in the block header to indicate which shards the output will be sent to. The node only needs to check the Bloom filter to determine whether there is a related output. In our two-layer structure, since the root chain network is responsible for maintaining the security of the system, nodes can freely join one or more shards without reshuffling the network, thus avoiding the overhead of data migration.

[0067] At the same time, in order to reduce the storage cost of the root chain and shards, checkpoints are introduced to summarize the entire state of the blockchain. Create a checkpoint cp for shard i in block segment e i,e The nodes of the shard execute the following steps: At the end of the block segment e (determined by the block height, for example, every 2048 blocks is considered a block segment), the node stores the UTXO in a sorted Merkle tree and puts the root hash of the Merkle tree into the head of the checkpoint. Since each node can build the same ordered Merkle tree, the checkpoint can be verified by each node. Afterwards, if the checkpoint is confirmed by the entire network, the checkpoint cp can be safely discarded i,e Previous block data.

[0068] Optionally, in step 5, we introduce a market incentive mechanism to dynamically adjust the computing power distribution between shards and the root chain. Under the incentive mechanism, nodes tend to choose shards with lower loads, balancing the computing power and transaction processing capabilities between shards, thereby avoiding regular reshuffling of the network. is a security parameter, HashPower(m) represents the total hash power of malicious nodes, HashPower(w) represents the hash power of the entire network, and represents the proportion of Byzantine nodes that the system can tolerate. Then the definition of Θ is as follows:

[0069]

[0070] To ensure that the root chain occupies most of the network's computing power (e.g. >50%), it is difficult for malicious nodes to launch attacks. Therefore, the total hash power of the root chain HashPower(r) is:

[0071]

[0072] Then for the total hash power of the root chain HashPower(r), we have:

[0073] HashPower(r)>2·Θ·HashPower(w)

[0074] At the same time, the computing power is evenly distributed among the shards so that each shard can work normally. Let HashPower(s) represent the computing power of each shard, and N represents the number of shards, then:

[0075]

[0076] We assume that most nodes are rational, that is, they are driven by their own interests and choose to work in the shard with the richest rewards. To achieve this goal, the block reward should be designed reasonably to ensure that the same computing power can get the same reward no matter which shard it works on. Let BlockReward(r) and BlockReward(s) represent the reward obtained for generating a block on the root chain and the block respectively. BlockInterval(r) and BlockInterval(s) represent the average time interval for generating new blocks on the root chain and the shard respectively. Therefore, the block rewards of the root chain and the shard should satisfy the following formula:

[0077]

[0078] When a new node joins the network, it will try to find the most profitable shard. The new node will first calculate the per-hash revenue G of all shards and select the shard with the highest revenue. Let P be the current hash power, then the per-hash revenue G is defined as follows:

[0079]

[0080] Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solution of the present invention can be modified or replaced by equivalents without departing from the purpose and scope of the technical solution, which should be included in the scope of the claims of the present invention.

Claims

1. A method for optimizing the scalability and performance of Internet of Vehicles blockchain based on sharding technology, characterized by: The method comprises the following steps: Step 1: Build the root chain network and sharding network structure, and perform sharding design; Step 2: Use flexible consensus mechanism to process single-shard transactions; Step 3: Use coordination between multiple shards to process cross-shard transactions; Step 4: Use state sharding and ledger pruning to reduce storage overhead; Step 5: Use market incentives to dynamically adjust the computing power distribution of the root chain and shards.

2. According to claim 1, a method for optimizing the scalability and performance of a blockchain for Internet of Vehicles based on sharding technology is characterized by: The specific process of step 1 includes: We design a two-layer architecture consisting of a root chain network and a shard network. The root chain network is responsible for overall security and cross-shard transaction verification, and maintains the global ledger; the shard network processes transactions in parallel on multiple independent shards, and each shard maintains its own ledger to share the storage and computing burden. We set up transaction sharding to process transactions in parallel through sharding, thereby improving transaction throughput and scalability. Transactions are assigned to specific shards, and the target shard is specified based on the input address of the transaction. That is, the address is formed into a "composite address" by splicing the block address and the shard ID. According to the distribution of the input and output addresses of the transaction, transactions are divided into the following three categories: (1) the input and output addresses are both in the same shard (single-shard transaction); (2) the input address is in the same shard, but the output addresses are distributed in different shards (special single-shard transaction); (3) the input and output addresses are distributed in different shards (cross-shard transaction). Among them, the inputs of single-shard transactions and special single-shard transactions are in the same shard, so they can be fully verified in a single shard. The sharding network consists of multiple shards, each of which is responsible for maintaining disjoint transaction ledgers and processing a set of disjoint transactions.

3. According to claim 2, a method for optimizing the scalability and performance of a blockchain for Internet of Vehicles based on sharding technology is characterized by: In step 2, we use the idea of ​​flexible arbitration sets to weaken the requirement of "all arbitration sets must intersect" to "only arbitration sets in different stages need to intersect". Therefore, we only need to ensure that the arbitration set (Q1) of the first stage intersects with the arbitration set (Q2) of the second stage, allowing performance to be improved by adjusting the size of Q1 and Q2. The performance of the protocol can be optimized by reducing the size of Q2 (improving the efficiency of the second stage) while increasing the size of the less used Q1. If the arbitration set on the node set is safe, then the arbitration sets used in the first and second stages should be intersecting. That is, We define the tolerable number of regional failures f z and the number of node failures f that a region can tolerate before losing availability n In order to tolerate f in each region n Crash failure, we choose any f in the area n +1 node. In addition, in order to tolerate f in Z regions z Secondary fault, Q1 in Q1 from Zf z Select from the regions, q2 in Q2 from f z +1 region to choose from. Based on the above assumptions, the arbitration set is defined as follows: Where SUBSET q represents a subset of q, and Cardinality(q) represents the number of elements in set q. We define F min is the size of the fault set F under the worst fault distribution, that is, the minimum number of faults that violate the availability of read / write operations for any item. If all faults are concentrated on a specific q∈Q2, then q∈Q2 will be completely ineffective after Cardinality(Q2) faults occur. F min The formula is as follows: F min =Min(Cardinality(Q2),Cardinality(Q1))-1 We define F max is the size of the fault set F in the best case of fault distribution in the grid. In this case, the fault misses the union of the Q1 quorum set and the Q2 quorum set, leaving at least one Q1 quorum set and one Q2 quorum set intact. F max The formula is as follows: F max =N-Cardinality(Q1)-Cardinality(Q2)+(f z +1)*(f n +1) Based on this, a multi-leader protocol based on flexible arbitration sets is proposed. The multi-leader protocol based on flexible arbitration sets consists of two phases. In the first phase, phase 1 of multiple concurrent leaders is executed on q1∈Q1, stealing the ownership / leadership of the object from each other. In the second phase, the leader submits an update request to the object. When executing phase 2, the selected q2∈Q2 comes from the region where the leader is located (and nearby regions) to improve locality. The leader can execute the second phase multiple times until other nodes steal the object. Phase 1 of the protocol is executed only when a node needs to steal an object from a remote leader, or when a client requests a new object that does not exist in the system. This phase causes the election number of the object involved to increase. Once a node becomes the owner / leader of an object, it executes phase 2 multiple times on that object to submit commands / updates, incrementing the slot number at each iteration, while the object's election number remains unchanged. When a node needs to steal an object from another leader to process a client request, it first consults its internal cache to determine the last ballot number used on the object and performs a phase one operation on some q1∈Q1 with a higher ballot number. If the candidate node is able to surpass the current leader's ballot number, the object stealing succeeds. Once the object is stolen, the old leader can no longer operate on the object because the object is now associated with a higher ballot number than the old leader's ballot number. Object stealing can occur while some commands have not yet completed, so the new leader must revert any object commands that have been accepted but not yet committed. We maintain independent ballot numbers for each object, thus isolating the impact of object theft. This will also lead to the problem of leader duel, where two nodes steal different objects from each other by continuously proposing higher ballot numbers than each other. To solve this problem, we take two additional protective measures: (1) in the case of the same ballot number, the ballot conflict is resolved by the region ID and node ID, and (2) if a new duel iteration is still started, a random backoff mechanism is adopted. Nodes within the shard generate blocks through a flexible consensus mechanism and add transactions to the blockchain. Then the root chain network verifies the legitimacy of the shard block and generates a root block, which finally confirms the transaction.

4. According to claim 3, a method for optimizing the scalability and performance of a blockchain for Internet of Vehicles based on sharding technology is characterized in that: In step 3, for cross-shard transactions, the cross-shard communication overhead directly affects the efficiency of cross-shard transaction processing and the communication burden of the entire system. Because the root chain maintains the entire ledger and does not need to communicate with other shards, we assign cross-shard transactions to the root chain network to eliminate cross-shard communication. Therefore, we reduce the number of cross-shard transactions by the following two methods. First, since we assign transactions to shards based on the input addresses of the transactions, we can encourage users to generate new addresses belonging to the same shard so that users can perform as many intra-shard transactions as possible, thereby obtaining fast confirmation and paying less transaction fees. Second, in most cases, it is not necessary to maintain the atomicity of transactions. Therefore, the number of cross-shard transactions can be further reduced by splitting cross-shard transactions into several intra-shard transactions. For example, a transaction TX:In(A+B)→Out(C) can be split into TX1:In(A)→Out(C) and TX2:In(B)→Out(C). This split operation can be performed automatically by the node. Under this strategy, the number of cross-shard transactions can be effectively controlled. Finally, a small number of cross-shard transactions that must remain atomic can be processed through the root chain network.

5. According to claim 4, a method for optimizing the scalability and performance of the Internet of Vehicles blockchain based on sharding technology is characterized by: In step 4, the entire address space is logically divided into multiple non-intersecting parts. Each shard is only responsible for maintaining the ledger of its own shard, rather than the complete blockchain, which can reduce the storage burden of the shard nodes. State sharding faces the challenge of data availability. Since the state of the system is not replicated between all shards, the network can no longer verify transactions that depend on the attacked shard. Therefore, the designated node in the root chain network stores the entire ledger. We introduced a Bloom filter structure in the block header to indicate which shards the output will be sent to. The node only needs to check the Bloom filter to determine whether there is a related output. In our two-layer structure, since the root chain network is responsible for maintaining the security of the system, nodes can freely join one or more shards without reshuffling the network, thus avoiding the overhead of data migration. At the same time, in order to reduce the storage cost of the root chain and shards, checkpoints are introduced to summarize the entire state of the blockchain. Create a checkpoint cp for shard i in block segment e i,e The nodes of the shard execute the following steps: At the end of the block segment e (determined by the block height, for example, every 2048 blocks is considered a block segment), the node stores the UTXO in a sorted Merkle tree and puts the root hash of the Merkle tree into the head of the checkpoint. Since each node can build the same ordered Merkle tree, the checkpoint can be verified by each node. Afterwards, if the checkpoint is confirmed by the entire network, the checkpoint cp can be safely discarded i,e Previous block data.

6. According to claim 5, a method for optimizing the scalability and performance of a blockchain for Internet of Vehicles based on sharding technology is characterized by: In step 5, we introduce a market incentive mechanism to dynamically adjust the computing power distribution between shards and the root chain. Under the incentive mechanism, nodes tend to choose shards with lower loads, balancing the computing power and transaction processing capabilities between shards, thereby avoiding regular reshuffling of the network. is a security parameter, HashPower(m) represents the total hash power of malicious nodes, HashPower(w) represents the hash power of the entire network, and represents the proportion of Byzantine nodes that the system can tolerate. Then the definition of Θ is as follows: To ensure that the root chain occupies most of the network's computing power (e.g. >50%), it is difficult for malicious nodes to launch attacks. Therefore, the total hash power of the root chain HashPower(r) is: Then for the total hash power of the root chain HashPower(r), we have: HashPower(r)>2·Θ·HashPower(w) At the same time, the computing power is evenly distributed among the shards so that each shard can work normally. Let HashPower(s) represent the computing power of each shard, and N represents the number of shards, then: We assume that most nodes are rational, that is, they are driven by their own interests and choose to work in the shard with the richest rewards. To achieve this goal, the block reward should be designed reasonably to ensure that the same computing power can get the same reward no matter which shard it works on. Let BlockReward(r) and BlockReward(s) represent the reward obtained for generating a block on the root chain and the block respectively. BlockInterval(r) and BlockInterval(s) represent the average time interval for generating new blocks on the root chain and the shard respectively. Therefore, the block rewards of the root chain and the shard should satisfy the following formula: When a new node joins the network, it will try to find the most profitable shard. The new node will first calculate the per-hash revenue G of all shards and select the shard with the highest revenue. Let P be the current hash power, then the per-hash revenue G is defined as follows:

Images