CN117579635A

CN117579635A - Dynamic state slicing method of block chain architecture

Info

Publication number: CN117579635A
Application number: CN202311530369.9A
Authority: CN
Inventors: 汪晓丁; 阙友雄; 林晖; 镇子航
Original assignee: Fujian Normal University; Institute of Tropical Bioscience and Biotechnology Chinese Academy of Tropical Agricultural Sciences
Current assignee: Fujian Normal University; Institute of Tropical Bioscience and Biotechnology Chinese Academy of Tropical Agricultural Sciences
Priority date: 2023-11-16
Filing date: 2023-11-16
Publication date: 2024-02-20

Abstract

The invention discloses a dynamic state slicing method of a block chain architecture, which comprises the following steps: first, the method solves the problems of cross-shard transactions and reconfigurations in blockchain state shards through graph partitioning and relay transactions. We then translate the search problem of the optimal block generation strategy into a markov decision process. The number of fragments, the block interval and the block size are dynamically adjusted through deep reinforcement learning, so that the throughput of the block chain and the duty ratio of non-malicious nodes are improved. The invention aims to solve the problems of server single-point failure, user privacy disclosure and public arbitration in a crowdsourcing system, and improve the performance and the safety of the system.

Description

Dynamic state slicing method of block chain architecture

Technical Field

The invention relates to the technical field of block chains, in particular to a dynamic state slicing method of a block chain architecture.

Background

The prior art is based on cryptography and P2P networks, and constructs blockchains, which are non-tamper-able and distributed with decentralization features, widely applied to solve crowdsourcing system problems such as single point failure, privacy disclosure and mutual trust. However, conventional crowdsourcing systems still suffer from server single point failure, user privacy disclosure, and unfair arbitration, facilitating the conversion of crowdsourcing operations into blockchain transactions in recent years to improve security and reliability. However, the scalability of the blockchain is limited by a consensus mechanism, so that the performance of the crowdsourcing system based on the blockchain is limited, and technologies such as layer0, layer1 and layer2 are proposed to solve, but the problem of the scalability of the traditional blockchain still needs to be further innovated.

On the other hand, the scalability of the crowdsourcing system based on the blockchain is improved, and meanwhile, the system security and the decentralization are required to be balanced. Traditional blockchain relies on all nodes to ensure transaction consensus safety, high storage cost promotes participation thresholds, and decentralization and safety are limited. Redundant data storage in a block chain based crowdsourcing system results in wasted resources. The state slicing block chain crowdsourcing system reduces the storage cost by dividing the state information, improves the safety and removes the center. However, in the state slicing technology, the cross-slice transaction needs to ensure atomicity, and the influence of malicious and downtime nodes is reduced. In the state slice reconfiguration phase, excessive node reconfiguration affects stability. How to balance the advantages and problems of state slicing technology, and improve the performance of a blockchain system, and form a new research challenge.

In general, to address the problem of limited performance of current blockchain-based crowdsourcing systems, the following four challenges are faced: 1. the problem that expandability is difficult to improve exists in the block chain; 2. the problem of centralization and safety of the block chain link point storage space is restricted due to the fact that the block chain link point storage space is too high; 3. in order to promote the scalability of the blockchain, the problem of reduced safety and stability is caused; 4. to adapt to various scenes, the problem of how to dynamically adjust the blockchain.

Disclosure of Invention

The invention aims to solve the problems of single point failure of a server, leakage of user privacy and unfamiliar arbitration in a crowdsourcing system, and simultaneously improve the performance and the safety of the system.

The technical scheme adopted by the invention is as follows:

a dynamic state slicing method of a block chain architecture comprises the following steps:

s1, defining and initializing a time period epoch;

s2, constructing a bottom state slicing blockchain environment of a crowdsourcing system based on the blockchain, wherein the bottom state slicing blockchain environment comprises nodes for setting the blockchain, a module for controlling joining of the nodes and a transaction flow for confirming the state slicing blockchain;

s3, the training decision process expresses the joint optimization problem as a Markov decision problem consisting of a system state, a system action and a cost function, and combines a deep neural network with reinforcement learning to train a model so as to realize dynamic optimization; the method specifically comprises the following steps:

s30, describing an observation state of a system environment by using a state space S (t), wherein the state comprises transmission rate, computing power and transaction flow snapshot among nodes, and the specific expression is as follows:

S(t)＝{μ(t),σ(t),γ(t)}

Wherein μ (t) = { u _i,j The transmission rate between nodes, σ (t) = { σ } is represented _i Y (T) represents the current transaction flow snapshot, t=1,..t;

s31, defining an action space A (t), wherein the action space at the time t of the time period epoch is expressed as follows:

A(t)＝{K(t),S _B (t),T _I (t)}

wherein K (t) is the number of slices of the slice, K (t) is {8,16,., K ^max }；T _I (t) is the block out interval time of the block, S _B (t) is the maximum block size, < >>

S32, designing a cost function Q (S, A), and realizing training of deep reinforcement learning by using experience playback and a fixed target network mechanism through a double Q network structure; the cost function Q of DSSBD is denoted as,

wherein ρ ε (0, 1) is a discount factor for reducing the impact of historical decisions;

s33, in the DSSBD, at the time t of each time period epoch, the intelligent agent observes the state S (t) of the system environment, including the transmission rate between points, the computing power and the snapshot of a state diagram; then, a strategy is explored or utilized through an epsilon-greedy algorithm, and an action A (t) is selected to determine the block size, the block outlet interval and the number of fragments; meanwhile, the intelligent agent obtains an immediate return reward R (t), and the state of the system is changed into S (t+1) according to a state transition matrix;

S4, judging whether corresponding parameters of the construction environment and the training decision in the current time period epoch are converged or not; if so, constructing a blockchain architecture based on the final parameters; otherwise, the next time period epoch is started and S2 is performed.

Further, the step S2 of setting the nodes of the blockchain includes setting a relay Node R-Node and a slicing Node S-Node, and specifically includes the following steps:

s20, setting a relay Node R-Node, wherein a relay account is set on the relay Node and added into more than two fragments for processing transactions from different fragments, namely cross-fragment transactions;

s21, setting a slicing Node S-Node, wherein the slicing Node is generated through application and election and does not add any specific state slicing, and the slicing Node is responsible for planning the slicing nodes according to transaction load and safety and for reconfiguring the nodes in each time period epoch.

Further, the modules added into the node comprise a slicing module, a graph dividing module, a node reconfiguration module and a slicing security module; the method specifically comprises the following steps:

s22, the slicing module sets an initial slicing strategy: any newly added blockchain node needs to solve a hash problem to determine the shard that the newly added blockchain node specifically adds;

S23, the graph dividing module sets a graph dividing strategy: graph division is performed through a METIS algorithm based on the relevance between transactions, so that the number of cross-piece transactions is reduced;

s24, a reconfiguration module of the node sets a reconfiguration strategy: when each round of time period epoch starts, nodes of each fragment carry out consensus on the transactions in the transaction pool according to the reconfiguration result of the previous round of time period epoch, and legal transactions are packed into blocks and linked into chains; meanwhile, the slice Node S-Node reads and records legal transactions.

S25, the slicing security module sets a slicing security policy: the security is improved by a mode of merging calculation; when all nodes of the two fragments mutually store all state information of the two fragments, the two fragments are combined into the same fragment; for a POW consensus system, the number of malicious nodes tolerated by the whole systemWherein N is the total node number;

the system has no merging calculation at all, and the number of malicious nodes tolerated by each fragment is as followsWhere k is the number of slices; worst case maximum number of slices +.>

Further, in step S22, for the account-based system, the fragment to which the account belongs is quickly determined by the hash value of the first or last digits of the account address.

Further, the METIS algorithm of the division map in step S23 specifically includes the following steps:

in each time period epoch, abstracting accounts involved in transaction as vertexes of a graph, abstracting transactions among the accounts as undirected edges, and expressing the weight of the edges as the number of the two accounts involved in the transaction in the current time period epoch; if the account does not have transaction in the current time period epoch, the consideration of graph division is not carried out so as to reduce the cost of system reconfiguration.

UsingDefining a transaction flow state snapshot map of the epoch, wherein gamma (t) is a matrix of M by M, and M is the number of accounts involved in all transactions in the epoch in a time period; when the transaction number of the accounts i and j in the block is x at the time t of the time period epoch, corresponding +.>When i and j are not present, then +.>When accounts i and j are not packed into blocks at time t, then both accounts are not placed in gamma (t).

Further, in step S24, after all the transactions in the round are read, the segment Node S-Node performs state division on the nodes according to the graph division policy, and the division result achieves consensus in the segment S-card to form S-Block; S-Block is recorded in the S-Board chain and broadcast to other nodes; and (3) the nodes of other slices are reconfigured according to the content of the S-Block, the slices are adjusted, the S-Block is used as a first Block which achieves consensus in the current time period epoch, and the first Block is recorded in a chain of the nodes.

Further, the transaction flow of the confirmation state slicing blockchain in step S2 specifically includes the following steps:

s26, modifying a state tree of the blockchain system: based on the number of maximum slices K ^max Adding a K at leaf nodes of the state tree ^max A field of a bit length for representing a fragment to which the account address belongs; for R-Node, according to the reserved state information of multiple fragments, multiple bit positions '1' are included in the field, so that the time complexity of inquiring whether one transaction is a cross-fragment transaction is simplified to 0 (1), and the time complexity of inquiring account balance is simplified to 0 (n);

s27, processing a cross-slice transaction: the cross-piece transactions include front cross-piece transactions and rear cross-piece transactions; the front-piece-crossing transaction relates to generation and verification of a relay node, the rear-piece-crossing transaction relates to creation and broadcasting of the relay node, and finally confirmation of the piece-crossing transaction is realized;

s28, optimizing transaction confirmation time delay:

for on-chip transaction, the confirmation delay requirement of the transaction is met through the block-out delay, the broadcast delay and the verification delay of the block-out node; for the cross-piece transaction, combining the relay delay of the relay transaction, and calculating and meeting the confirmation delay requirement of the cross-piece transaction through the processing flow of the front cross-piece transaction and the rear cross-piece transaction.

Further, the cross-slice transaction process in step S27 specifically includes the following steps:

s27-1, firstly creating an original transaction Θ in the sending account A _raw The receiving account is B, the number of tokens sent is v, the relay account is C1, and an appropriate transaction lock time H is selected _lock The original transaction is then sent to the relay account C1, as shown below,

Θ _raw ：＝<<B，v，C，H _lock ，η _sender ，η _broker >，σ _A >

wherein eta _sender And eta _relay Transaction nonce, sigma, represented as sub-account C1 of transmitting account a and relay node C in shard #1 _A A signature denoted as account a;

s27-2, after the relay node C receives the original transaction, a pre-cross transaction Θ is created _pre Broadcasting to a block chain network; the nodes of each segment receive theta _pre After that, the theta is verified by the signature _pre And calculates the address of sender a; after inquiring the modified state tree, the nodes of each fragment acquire a fragment sequence of a source address and a destination address, and forward the transaction to fragments #1 and #2; after verifying that the transaction is legal, the pre-cross transaction will be added to the pool of fragment #1 waiting to be packaged, Θ _pre The expression is as follows,

Θ ₁ ：＝<<Type1，Θ _raw ，H _current >，σ _C >

wherein, type1 is denoted as front-stride transaction, H _current Expressed as the current block height, sigma _C A signature representing the relay account C1;

s27-3, packaging Θ _pre After the block is reached, the sender A transfers v tokens to the relay account C1 of the relay account C1, reserves the corresponding tokens until the transaction lock expires, and adds one to the nonce of the sender A to avoid replay attack;

S27-4, after the front cross-piece transaction is confirmed, the relay node C creates a post-cross transaction theta _post Broadcasting to the fragment 2 where the destination account B is located through the relay node C;

s27-5, when theta _post Is added to the transaction pool of the fragment 2 after being validated; ensuring that the account balance C2 of the relay node in the fragment 2 is greater than the token v, Θ _post The expression is as follows,

Θ ₂ ：＝<<Type2，Θ _raw >，σ _C >

wherein type 2 is denoted as post-cross-slice transaction, σ _C A signature representing the relay node account C;

s27-6, after the cross-piece transaction is carried out after packaging, if the block-out height does not exceed the transaction locking height, transferring v tokens to a receiver B by a relay account C2, and adding one to the nonce of the relay account C2;

s27-7, if the transaction fails, the slice 2 willWill handle theta _pre Packing into a block, the nonce of the C2 account is incremented by 1, while the node in slice 2 sends a failure proof gamma to slice 1, gamma being expressed as follows,

γ：＝<Θ ₁ ，dest,H _dest ，{p _dest }>

where dest represents the sequence number of the target fragment, H _dest Block height, p, representing target slice _dest Representing a path from a merkle tree root node to a previous sharded transaction; when the failure proof is verified by the node of segment 1, the failure proof is packed into the block of segment 1, and the lock balance v in C is returned to A.

Further, the transaction confirmation delay in step S28 specifically includes the following steps:

S28-1, delay T of on-chip transaction _Latency Ensure not to be greater than the limit time delay T _Limit ＝T _I 。

T _Latency ＜＝T _Limit

S28-2, a confirmation time delay calculation formula of the cross-slice transaction is as follows:

wherein,for the block out time delay of the respective slice, < >>For the propagation delay of the respective slice, +.>For the verification delay of the respective slices,

s28-2, limiting time delay T of cross-slice transaction _Limit ＝H _lock *T _I 。

Further, step S33 includes the steps of:

s33-1, expressing the cost function as a combination,

maxQ(S，A)

C1：T _Latency ＜T _I

C2：

wherein Q (S, a) represents a long-term reward for the system;

s33-2, setting corresponding incentives and penalties in the immediate return function R (t), expressed as follows,

wherein, xi (t) represents throughput of the present round system, and ψ (t) represents the number ratio of the present round of cross-chip transactions; phi (t) represents the mean square error of the number of each sliced transaction in the current round of time period and is used for representing the balance degree of each sliced transaction load; delta (t) represents the number of nodes that need to be reconfigured for this round; omega _S 、ω _C 、ω _D 、ω _R Weight coefficients representing the parameters;

the definition of the blockchain throughput xi (t) is as follows,

where λ represents the average size of the transaction;

the actual throughput in a DSSBD system after redundancy removal is defined as,

wherein g _k Representing the number of cross-slice transactions in the kth slice.

S33-3, the cost function Q of dssbd is denoted as,

Where ρ ε (0, 1) is a discount factor for reducing the impact of historical decisions.

By adopting the technical scheme, the invention provides a block chain architecture based on dynamic state slicing using deep reinforcement learning, which is called DSSBD. The method is used for solving the problem that the performance of the crowdsourcing system is reduced when the blockchain is in a non-optimal balance state in decentralization, safety and expandability. To our knowledge, DSSBD is the first architecture in state-slicing blockchain that uses deep reinforcement learning to optimize slicing strategies and blockgeneration strategies, greatly improving the performance of blockchain-based crowdsourcing systems while guaranteeing blockchain security and transaction effectiveness.

Drawings

The invention is described in further detail below with reference to the drawings and detailed description;

FIG. 1 is a system model diagram of a method for dynamic state slicing of a blockchain architecture according to an embodiment of the present invention;

FIG. 2 is an illustration of an improved blockchain system status tree in accordance with an embodiment of the present invention;

FIG. 3 is a cross-slice transaction case according to an embodiment of the present invention;

fig. 4 is a block diagram of a Double DQN network according to an embodiment of the invention.

Description of the embodiments

For the purposes, technical solutions and advantages of the embodiments of the present application, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application.

As shown in one of fig. 1 to 4, the present invention discloses a method for dynamic state slicing of a blockchain architecture, comprising the steps of:

s1, continuously and circularly executing the whole block chain architecture based on dynamic state fragmentation in two processes of setting a block chain environment and dynamically adjusting parameters through deep reinforcement learning, so that epochs are defined, and the two processes are executed in each epoch until convergence, and iterating the steps of constructing the environment and training decisions;

s2, constructing a bottom state slicing blockchain environment of the crowdsourcing system based on the blockchain. The method comprises the steps of setting nodes of a blockchain, adding a segmentation module, a graph dividing module, a node reconfiguration module and a segmentation safety module of the nodes, and confirming the transaction flow of the state segmentation blockchain;

s3, the training decision process is to express the joint optimization problem as a Markov decision problem consisting of a system state, a system action and a cost function. And combining the deep neural network with reinforcement learning (DRL) training model to realize dynamic optimization.

The above-mentioned frame flow is shown in the system model diagram of fig. 1.

Further, the two main processes performed in each epoch specifically include the following steps:

In the blockchain consensus phase, blockchain consistency is achieved through consensus on transactions. For DSSBD, no matter whether the consensus protocol is POW or PBFT, the receiving and transmitting addresses belong to the transaction of the same slice, the consensus can be achieved only through the state information in the slice, and the state information of other slices is not needed to be used additionally. For transactions across slices, since the state information of the entire blockchain is divided into different slices, sub-consensus is formed in each partition by relay node auxiliary communication to verify the transaction and achieve consensus, and finally, the consensus of the complete transaction is formed.

In the Node reconfiguration phase, we need to perform a slice reconfiguration for all nodes except the S-Node. For DSSBD systems, the system's resistance to malicious nodes has to be reduced in order to increase the overall efficiency of the system. Thus, to avoid malicious nodes from aggregating in the same shard to control the entire blockchain system, we need to reconfigure the shards of the nodes. In the reconfiguration stage, according to the slicing strategy, the S-Node in the S-Shard forms consensus through the result of repartitioning Node slicing information through the round of epoch transaction. To reduce the cost of reconfiguration, each round of epoch ends with only partial reconfiguration of the active nodes of the round. In particular, by node reconfiguration, DSSBD simultaneously reduces the duty cycle of cross-slice transactions and optimizes the transaction load of each slice.

Further, the setting of the relay Node (R-Node) and the slicing Node (S-Node) in the step S2 is specifically as follows:

s20, setting a Relay Node (R-Node for short), wherein a Relay account exists, and the Relay account needs to be added into certain two (or more) fragments and is mainly used for processing transactions from different fragments, namely cross-fragment transactions. Compared with the common node, the relay node needs to participate in the consensus of a plurality of fragments, and the state information of the fragments is reserved, which is essentially equivalent to a full node storing the plurality of fragments. In particular, if it holds state information of all slices, it corresponds to one common full node before the slices.

However, in order to become a relay node, a quasi-relay account on the node needs to be subjected to certain stock right mortgage through an intelligent contract so as to avoid being wrongly performed after becoming the relay node. Therefore, one node is expected to become a relay node with more fragments, so that not only is more resources needed to store multi-fragment information, but also more equity is needed to be paid to mortgage, and in this way, the processing of the cross-fragment transaction can be effectively prevented from being too concentrated on an individual relay account. However, in order to encourage the node to become a relay node to process the cross-slice transaction, maintain the system operation and increase the degree of decentralization, a portion of the transaction fee will be transferred to the relay account.

S21, setting a Shard Node (S-Node for short), generating through application and election, not adding any specific state shards, and forming a new Shard S-Shard similar to a committee together, wherein the Shard Node is mainly responsible for planning the nodes of each Shard in each epoch according to transaction load and security, and is responsible for reconfiguration of the nodes.

Further, the various modules of the joining node in step S2 specifically include the following steps:

s22, setting an initial slicing strategy. To avoid the witch attack, any node that joins the blockchain newly would need to solve a hash problem to determine the shards it joins specifically. In particular, for account-based systems, the shard to which the account belongs can be quickly determined by the hash value of the first or last digits of its account address.

S23, setting a graph dividing strategy. Considering the relevance between transactions, we reduce the number of cross-slice transactions by performing graph partitioning through the METIS algorithm.

S24, setting a reconfiguration strategy. At the beginning of each round of epoch, nodes of each fragment share the transactions in the transaction pool according to the result of the last round of epoch reconfiguration, package legal transactions into blocks and link the blocks into chains. At the same time, the S-Node reads and records legal transactions. After all the transactions are read, the S-Node performs state division on the nodes according to a graph division strategy, and the division result can reach consensus in the S-card to form S-Block. The S-Block will be recorded in the chain of S-board and broadcast to other nodes. And the nodes of other slices are reconfigured according to the content of the S-Block, the slices are adjusted, the S-Block is used as the first Block which achieves consensus in the current epoch, and the Block is recorded in the own chain.

In order to ensure the safety and stability of the system in the reconfiguration process and minimize the reconfiguration cost, we need to consider the number delta (t) of the reconfiguration nodes in each round of epoch.

S25, setting a slicing security policy. Since the slicing strategy tends to divide frequently transacted nodes into the same slices, in order to resist the problem that the slices cause security degradation, we need to improve security by a way of merging computation. If all nodes of two slices mutually store all state information of the two slices, the two slices are essentially combined into the same slice, which is one way of realizing dynamic slicing.

From the security point of view, for a POW consensus system, the number of malicious nodes that the whole system can tolerateWhere N is the total number of nodes. In the worst case of consideration, i.e. the system has no merging computation at all, then the number of malicious nodes that can be tolerated per shard drops to +.>Where K is the number of slices. Then from the point of view of security the worst case maximum number of slices +.>

Further, the specific transaction process of the state slicing blockchain of the S2 comprises the following steps:

S26, in order to quickly distinguish whether the transaction type is a cross-chip transaction or an on-chip transaction, the state tree of the blockchain system needs to be modified. Since the maximum number of slices is K ^max Then the leaf node of the state tree needs to add a K ^max A field of a bit length for indicating the fragment to which the account address belongs. For R-Node, since it retains state information of multiple slices, there are multiple bits in the field that need to be located one. As shown in fig. 2, is a Modified State Tree case. In this way, the time complexity of querying whether a transaction is a cross-piece transaction is reduced to O (1) and the time complexity of querying the account balance is reduced to O (n).

S27, processing cross-piece transactions, including front cross-piece transactions and rear cross-piece transactions. The front-piece transaction relates to generation and verification of a relay node, the rear-piece transaction relates to creation and broadcasting of the relay node, and finally confirmation of the piece-crossing transaction is achieved.

S28, optimizing transaction confirmation time delay. For on-chip transactions, the validation delay requirements of the transactions are met by the outbound delays, broadcast delays, and validation delays of the outbound nodes. For the cross-piece transaction, the relay delay of the relay transaction is considered, and the confirmation delay requirement of the cross-piece transaction is calculated and met through the processing flows of the front cross-piece transaction and the rear cross-piece transaction.

Further, the step S3 specifically includes the following steps:

s30, describing an observation state of the system environment by using a state space S (t), wherein the state includes a transmission rate, a computing power and a transaction flow snapshot between nodes.

S31, defining an action space A (T), wherein the action space A (T) comprises a fragment number K (T), a block outlet interval time T_I (T) and a maximum block outlet size S_B (T).

S32, designing a cost function Q (S, A), and realizing training of deep reinforcement learning by using experience playback and a fixed target network mechanism through a double Q network structure.

S33, in the DSSBD, at each epoch t, the agent observes the state S (t) of the system environment, including the transmission rate between nodes, the computing power and the snapshot of the state diagram. Then, the strategy is explored or utilized through an epsilon-greedy algorithm, and the action A (t) is selected to determine the block size, the block outlet interval and the number of fragments. At the same time, the agent gets an immediate rewards R (t), and the state of the system becomes S (t+1) according to the state transition matrix. Therefore, to handle the high-dimensional system state S (t), we need to use deep neural network Double DQN.

The METIS is a well-known heuristic graph partitioning tool that may partition a transaction flow snapshot into non-overlapping portions while taking into account workload balancing. In each epoch we abstract the accounts involved in the transaction as vertices of the graph, and transactions between accounts as undirected edges. Since the cost of a cross-piece transaction is primarily related to the number of transactions, the weight of an edge is expressed as the number of transactions that two accounts involve within this epoch. If the account does not have a transaction within this epoch, then no graph partitioning consideration is performed to reduce the cost of system reconfiguration.

Therefore we useTo define a snapshot of the transaction flow state of the epoch, γ (t) is a matrix of M x M, M being the number of accounts involved in all transactions within the epoch. If the transaction number of the accounts i and j in the block is x when epoch is t, corresponding +.>If there is no transaction between i and j +.>If the account i, j is at t, there is noAny transactions are packed into blocks, then these two accounts should not be put into account for γ (t).

Further, the step S27 of the cross-slice transaction process specifically includes the following steps:

for a cross-slice transaction, the consensus process of the transaction needs to be performed in two steps, since the state of the account is split into different slices. As shown in fig. 3, this is a typical cross-slice transaction case in DSSBD.

An original transaction theta is created in a sending account A _raw The receiving account is B, the number of tokens sent is v, the relay account is C1, and an appropriate transaction lock time is selected (with H _lock Representation), essentially the number of subsequent blocks. The original transaction is then sent to the relay account C1, which is represented as follows,

Θ _raw ：＝<<B,v,C,H _lock ,η _sender ,η _broker >,σ _A >

wherein eta _sender And eta _relay Transaction nonce, sigma, represented as sub-account C1 of transmitting account a and relay node C in shard #1 _A Represented as a signature of account a.

After receiving the original transaction, the relay node C creates a pre-cross transaction theta _pre Broadcast into the blockchain network. The nodes of each segment receive theta _pre After that, the theta is verified by the signature _pre And calculates the address of sender a. After querying the modified state tree, the nodes of each shard may obtain the shard sequence of source and destination addresses and forward the transaction to shard #1 and shard #2. After verifying that the transaction is legitimate, the pre-cross transaction will be added to the pool of fragment #1 to wait for packaging. Theta (theta) _pre The expression is as follows,

Θ ₁ ：＝<<Type1,Θ _raw ,H _current >,σ _C >

wherein, type1 is denoted as front-stride transaction, H _current Expressed as the current block height, sigma _C Representing the signature of the relay account C1.

At packaging theta _pre After the block is reached,sender a will transfer v tokens to relay account C1, with account C1 holding the tokens until the transaction lock expires. At the same time, sender a's nonce will be incremented to avoid replay attacks.

After the current cross-slice transaction is confirmed, the relay node C creates a post-cross transaction Θ _post This transaction is broadcast by relay node C to the shard 2 where destination account B is located. When theta is _post After being validated, it will be added to the pool of fragments 2. In particular, it is necessary to ensure that the account balance C2 of the relay node at slice 2 is greater than the token v. Theta (theta) _post The expression is as follows,

Θ ₂ ：＝<<Type2,Θ _raw >,σ _C >

wherein type 2 is denoted as post-cross-slice transaction, σ _C Representing the signature of relay node account C.

After the cross-slice transaction is completed after packaging, if the out-of-block height does not exceed the transaction locking height, the relay account C2 will transfer v tokens to the recipient B. Meanwhile, to avoid replay attacks, the nonce of relay account C2 will also be incremented.

If the transaction fails, fragment 2 will send Θ because the previous cross-fragment transaction has been broadcast into the network _pre Packing into a block, the nonce of the C2 account would also be incremented by 1, while the node in slice 2 would send a failure proof γ to slice 1. The symbol gamma is represented as follows,

γ：＝<Θ ₁ ，dest,H _dest ，{p _dest }>

where dest represents the sequence number of the target fragment, H _dest Block height, p, representing target slice _dest Representing the path from the merkle tree root node to the previous sharded transaction. Once the failure proof is verified by the node of segment 1, it will be packed into the block of segment 1 and the lock balance v in C will be returned to a.

Further, the step S28 transaction confirmation delay specifically includes the following steps:

for on-chip transactions, the security is commonly ensured by all nodes within the segment through consensus. The confirmation delay of the transaction needs to consider the block sectionBlock-out time delay of point collision through hashPropagation delay ∈of block broadcast>And verification delay of block->That is to say,

thus, for on-chip transactions, only a time delay T is required _Latency Ensure not to be greater than the limit time delay T _Limit ＝T _I 。

T _Latency ＜＝T _Limit

For a cross-slice transaction, the validation consensus of the transaction needs to be completed in two steps in different slices. For pre-cross-card transactions and pre-cross-card transactions divided by relay nodes, the outbound latency in the respective slices also needs to be consideredPropagation delay->And verification delay->So that it satisfies the above formula.

In addition, relay delay also needs to be considered in terms of the whole cross-slice transactionBecause in DSSBD systems, the relay of the relay transaction is done locally at the relay node, the relay latency is negligible. The validation delay calculation formula for the cross-slice transaction is as follows.

In addition, DSSBD system passes transaction Ha Xisuo H _lock The atomicity of the transaction is ensured, and the time delay T is limited for the cross-slice transaction _Limit ＝H _lock *T _I 。

Further, the step S30 of defining the state space S (t) specifically includes the following steps:

We describe the observed state of the system environment at discrete epoch times T using S (T), where t=1, …, ·t.

S(t)＝{μ(t)，σ(t)，γ(t)}

Wherein μ (t) = { u _i，j The transmission rate between nodes, σ (t) = { σ } is represented _i The computing power of the node is denoted, and gamma (t) denotes the current transaction flow snapshot, the definition of which is specified in the { graph partitioning strategy }.

Further, the defining the action space a (t) in the step S31 specifically includes the following steps:

in the Layer2 Layer block chain scalability technique, the number of slices K of a slice and the block-out interval time T of a block _I And maximum out block size S _B Is a major factor in determining system performance. Therefore, the action space at epoch t is expressed as follows:

A(t)＝{K(t)，S _B (t)，T _I (t)}

wherein K (t) is {8,16, …, K ^max }，

Further, the step S32 of designing the cost function Q (S, a) specifically includes the following steps:

in deep reinforcement learning, agents can learn the optimal strategy directly or indirectly by maximizing long-term rewards. In particular, in the Double DQN algorithm, the long-term rewards are estimated Q values under different states, and agents indirectly learn strategies by maximizing the Q values. At the same time, the basic security and latency constraints also need to be met when learning decisions to improve blockchain performance, and therefore the cost function is expressed as a combination of,

maxQ(S，A)

C1：T _Latency ＜T _I

C2：

Where Q (S, A) represents the long-term rewards of the system, and in order to meet the security and latency constraints, corresponding incentives and penalties are set in the immediate return function R (t), expressed as follows,

wherein, xi (t) represents throughput of the present round system, and ψ (t) represents the number ratio of the present round of cross-chip transactions; phi (t) represents the mean square error of the number of each sliced transaction in the round and is used for representing the balance degree of the loads of each sliced transaction; delta (t) represents the number of nodes that need to be reconfigured for this round; omega _S 、ω _C 、ω _D 、ω _R Weight coefficients representing the respective parameters.

In addition, the definition of the blockchain throughput, xi (t), is as follows,

where λ represents the average size of the transaction. Since a cross-slice transaction will be relayed to another slice, in the definition of throughput, a cross-slice transaction will be repeatedly computed twice. Thus, after removing redundancy, the actual throughput in DSSBD systems is defined as,

Therefore, the cost function Q of DSSBD can be expressed as,

Further, the Double DQN network structure in step S33 is shown in fig. 4, and specifically includes the following steps:

In DSSBD, at each epoch t, the agent observes the state S (t) of the system environment, including a snapshot of the transmission rate, computing power, and state diagram between nodes. Then, the strategy is explored or utilized through an epsilon-greedy algorithm, and the action A (t) is selected to determine the block size, the block outlet interval and the number of fragments. At the same time, the agent gets an immediate rewards R (t), and the state of the system becomes S (t+1) according to the state transition matrix.

Therefore, to handle the high-dimensional system state S (t), we need to use deep neural networks. As shown in the figure, in the Double DQN network, we adopt a mode of 'fixed target network' and 'experience playback', so that the stability of model training is improved. Specifically, through the "fixed target network", in the learning process, the weight of the fixed target Q network performs policy learning, updates the weight of the estimated Q network with the learned data, copies the weight of the estimated Q network to the target Q network after performing step G, and starts a new round of "fixed target network". And the advantage of off-point is exerted through 'experience playback', after each round of epoch, the intelligent agent stores the track in the playback space D in the form of (S (t), A (t), R (t), S (t+1)), then randomly selects a plurality of experiences (basic size) to train the deep neural network, eliminates the relevance among samples, reduces the variance of parameter update, and accelerates convergence.

In particular, to eliminate the problem of cumulative learning rewards in Q-learning being higher than the actual value, the DoubleDQN model determines an action with one of the networks each time the action value is updated by introducing two Q networks, and estimates the reward with the determined action and the other network. Finally, through the continuous learning strategies of the two Q neural networks, the system dynamically selects and adjusts the number of fragments, the block outlet interval time and the block size under different states, and the performance of the block chain system is improved under the condition that the restrictions of safety and time delay are met.

It will be apparent that the embodiments described are some, but not all, of the embodiments of the present application. Embodiments and features of embodiments in this application may be combined with each other without conflict. The components of the embodiments of the present application, which are generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the detailed description of the embodiments of the present application is not intended to limit the scope of the application, as claimed, but is merely representative of selected embodiments of the application. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present application.

Claims

1. A dynamic state slicing method of a block chain architecture is characterized in that: the method comprises the following steps:

s1, defining and initializing a time period epoch;

S(t)＝{μ(t),σ(t),γ(t)}

A(t)＝{K(t),S _B (t),T _I (t)}

2. The method for dynamic state slicing of a blockchain architecture of claim 1, wherein: the step S2 of setting the nodes of the block chain comprises setting a relay Node R-Node and a slicing Node S-Node, and specifically comprises the following steps:

3. The method for dynamic state slicing of a blockchain architecture of claim 1, wherein: the node adding module comprises a slicing module, a graph dividing module, a node reconfiguration module and a slicing security module; the method specifically comprises the following steps:

S25, the slicing security module sets a slicing security policy: the security is improved by a mode of merging calculation; when all nodes of the two fragments mutually store all state information of the two fragments, the two fragments are combined into the same fragment; for a POW consensus system, the number of malicious nodes tolerated by the whole systemWherein N is the total node number; the system has no merging calculation at all, and the number of malicious nodes tolerated by each fragment is +. >Where k is the number of slices; worst case maximum number of slices +.>

4. A method for dynamic state slicing of a blockchain architecture as in claim 3 wherein: in step S22, for the account-based system, the fragment to which the account belongs is quickly determined by the hash value of the first or last digits of the account address.

5. A method for dynamic state slicing of a blockchain architecture as in claim 3 wherein: the METIS algorithm of the division map in step S23 specifically includes the following steps:

UsingDefining a transaction flow state snapshot map of the epoch, wherein gamma (t) is a matrix of M by M, and M is the number of accounts involved in all transactions in the epoch in a time period; when the transaction number of the accounts i and j in the block is x at the time t of the time period epoch, corresponding +. >When i and j are not present, then +.>When accounts i and j are not packed into blocks at time t, then both accounts are not placed in gamma (t).

6. A method for dynamic state slicing of a blockchain architecture as in claim 3 wherein: in step S24, after all the transactions of the round are read, the nodes are divided into segments according to the state of the nodes by the segment nodes S-Node according to the graph dividing strategy, and the division results reach consensus in the segment S-card to form S-Block; S-Block is recorded in the S-Board chain and broadcast to other nodes; and (3) the nodes of other slices are reconfigured according to the content of the S-Block, the slices are adjusted, the S-Block is used as a first Block which achieves consensus in the current time period epoch, and the first Block is recorded in a chain of the nodes.

7. The method for dynamic state slicing of a blockchain architecture of claim 1, wherein: the transaction flow of the state-partitioned blockchain confirmation in the step S2 specifically comprises the following steps:

s26, modifying a state tree of the blockchain system: based on the number of maximum slices K ^max Adding a K at leaf nodes of the state tree ^max A field of a bit length for representing a fragment to which the account address belongs; for R-Node, according to the reserved state information of multiple fragments The field has a plurality of bit positions of '1' so as to simplify the time complexity of inquiring whether one transaction is a cross-piece transaction into O (1) and the time complexity of inquiring account balance into O (n);

s28, optimizing transaction confirmation time delay:

8. The method for dynamic state slicing of a blockchain architecture of claim 7, wherein: the step S27 of the cross-slice transaction flow specifically comprises the following steps:

wherein eta _sender And eta _relay Transaction nonce, sigma, represented as sub-account C1 of transmitting account a and relay node C in shard #1 _o A signature denoted as account a;

s27-2, after the relay node C receives the original transaction, a pre-cross transaction Θ is created _pre Broadcasting to a block chain network; the nodes of each segment receive theta _pre After that, the theta is verified by the signature _pre And calculates the address of sender a; in query modificationAfter the state tree, the nodes of each fragment acquire a fragment sequence of a source address and a destination address, and forward the transaction to fragments #1 and #2; after verifying that the transaction is legal, the pre-cross transaction will be added to the pool of fragment #1 waiting to be packaged, Θ _pre The expression is as follows,

s27-7, if the transaction fails, the fragment 2 will send Θ _pre Packing into a block, the nonce of the C2 account is incremented by 1, while the node in slice 2 sends a failure proof gamma to slice 1, gamma being expressed as follows,

where dest represents the sequence number of the target fragment, H _dest Block height, P, representing target slices _dest Representing a path from a merkle tree root node to a previous sharded transaction; when the failure proof is verified by the node of segment 1, the failure proof is packed into the block of segment 1, and the lock balance v in C is returned to A.

9. The method for dynamic state slicing of a blockchain architecture of claim 7, wherein: the step S28 transaction confirmation delay specifically includes the following steps:

T _Latency <＝T _Limit

10. The method for dynamic state slicing of a blockchain architecture of claim 1, wherein: step S33 includes the steps of: