CN117579635A - Dynamic state slicing method of block chain architecture - Google Patents
Dynamic state slicing method of block chain architecture Download PDFInfo
- Publication number
- CN117579635A CN117579635A CN202311530369.9A CN202311530369A CN117579635A CN 117579635 A CN117579635 A CN 117579635A CN 202311530369 A CN202311530369 A CN 202311530369A CN 117579635 A CN117579635 A CN 117579635A
- Authority
- CN
- China
- Prior art keywords
- transaction
- node
- slicing
- block
- account
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 41
- 239000012634 fragment Substances 0.000 claims abstract description 65
- 230000008569 process Effects 0.000 claims abstract description 14
- 230000002787 reinforcement Effects 0.000 claims abstract description 13
- 238000012790 confirmation Methods 0.000 claims description 19
- 230000009471 action Effects 0.000 claims description 18
- 230000006870 function Effects 0.000 claims description 18
- 239000003795 chemical substances by application Substances 0.000 claims description 11
- 238000012549 training Methods 0.000 claims description 11
- 230000005540 biological transmission Effects 0.000 claims description 10
- 238000012545 processing Methods 0.000 claims description 10
- 238000012795 verification Methods 0.000 claims description 9
- 241001229889 Metis Species 0.000 claims description 7
- 238000013528 artificial neural network Methods 0.000 claims description 7
- 238000004364 calculation method Methods 0.000 claims description 7
- 238000010586 diagram Methods 0.000 claims description 7
- 239000011159 matrix material Substances 0.000 claims description 7
- 238000004806 packaging method and process Methods 0.000 claims description 7
- 238000005457 optimization Methods 0.000 claims description 6
- 230000007774 longterm Effects 0.000 claims description 5
- 230000007246 mechanism Effects 0.000 claims description 4
- 238000012546 transfer Methods 0.000 claims description 4
- 230000007704 transition Effects 0.000 claims description 4
- 238000012856 packing Methods 0.000 claims description 3
- 238000010276 construction Methods 0.000 claims description 2
- 238000000638 solvent extraction Methods 0.000 abstract description 5
- 238000010200 validation analysis Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 230000001934 delay Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000011218 segmentation Effects 0.000 description 3
- 238000005192 partition Methods 0.000 description 2
- 241001481828 Glyptocephalus cynoglossus Species 0.000 description 1
- 230000004931 aggregating effect Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000001186 cumulative effect Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N3/00—Computing arrangements based on biological models
- G06N3/02—Neural networks
- G06N3/08—Learning methods
- G06N3/092—Reinforcement learning
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
- H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1014—Server selection for load balancing based on the content of a request
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1023—Server selection for load balancing based on a hash applied to IP addresses or costs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1061—Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
- H04L67/1065—Discovery involving distributed pre-established resource-based relationships among peers, e.g. based on distributed hash tables [DHT]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Business, Economics & Management (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computing Systems (AREA)
- Accounting & Taxation (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Computational Linguistics (AREA)
- Artificial Intelligence (AREA)
- General Health & Medical Sciences (AREA)
- Evolutionary Computation (AREA)
- Mathematical Physics (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Biophysics (AREA)
- Biomedical Technology (AREA)
- Molecular Biology (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Life Sciences & Earth Sciences (AREA)
- Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
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
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,
Θ 1 :=<<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,
Θ 2 :=<<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,
γ:=<Θ 1 ,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.
Further, the METIS algorithm of the division map in step S23 specifically includes the following steps:
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,
Θ 1 :=<<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,
Θ 2 :=<<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,
γ:=<Θ 1 ,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,
wherein g k Representing the number of cross-slice transactions in the kth slice.
Therefore, the cost function Q of DSSBD can be expressed as,
where ρ ε (0, 1) is a discount factor for reducing the impact of historical decisions.
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.
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.
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 (10)
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;
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.
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:
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.
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:
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 +. >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:
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).
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);
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.
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:
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,
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,
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,
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 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:
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 。
10. The method for dynamic state slicing of a blockchain architecture of claim 1, wherein: step S33 includes the steps of:
s33-1, expressing the cost function as a combination,
maxQ(S,A)
C1:T Latency <T I
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.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202311530369.9A CN117579635A (en) | 2023-11-16 | 2023-11-16 | Dynamic state slicing method of block chain architecture |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202311530369.9A CN117579635A (en) | 2023-11-16 | 2023-11-16 | Dynamic state slicing method of block chain architecture |
Publications (1)
Publication Number | Publication Date |
---|---|
CN117579635A true CN117579635A (en) | 2024-02-20 |
Family
ID=89861935
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202311530369.9A Pending CN117579635A (en) | 2023-11-16 | 2023-11-16 | Dynamic state slicing method of block chain architecture |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN117579635A (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN118042001A (en) * | 2024-04-12 | 2024-05-14 | 南京邮电大学 | Block chain self-adaptive slicing method for point-to-point energy transaction |
-
2023
- 2023-11-16 CN CN202311530369.9A patent/CN117579635A/en active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN118042001A (en) * | 2024-04-12 | 2024-05-14 | 南京邮电大学 | Block chain self-adaptive slicing method for point-to-point energy transaction |
CN118042001B (en) * | 2024-04-12 | 2024-06-14 | 南京邮电大学 | Block chain self-adaptive slicing method for point-to-point energy transaction |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Sompolinsky et al. | Accelerating bitcoin's transaction processing. fast money grows on trees, not chains | |
CN111026511B (en) | Block chain parallel system and method based on transaction data partition-chain fusion | |
CN117579635A (en) | Dynamic state slicing method of block chain architecture | |
CN112104558B (en) | Method, system, terminal and medium for implementing block chain distribution network | |
CN111371905B (en) | Block chain layering consensus proving system and method based on cloud computing | |
JP2023065543A (en) | Method and system for selectively using network coding for propagating transactions in block chain network | |
CN112600699B (en) | Dynamic overlay network topology construction method and device based on block chain cross-chain interaction | |
CN115361395A (en) | Internet of things data sharing method based on block chain payment channel network | |
WO2013052161A1 (en) | Unifying connected dominating set using localized two hop information with a flexible dominating factor | |
CN115668877A (en) | Method and system for generating a network configuration using a graph neural network | |
Mazumdar et al. | CryptoMaze: Privacy-preserving splitting of off-chain payments | |
Mai et al. | Packet routing with graph attention multi-agent reinforcement learning | |
CN113626875A (en) | Knowledge graph file storage method for block chain fragment enabling | |
CN108834173B (en) | Centralized optimization distribution method of wireless multi-hop network | |
Niya et al. | DLIT: a scalable distributed ledger for iot data | |
Mišić et al. | Optimal multi-tier clustering of permissioned blockchain systems for IoT | |
Kiayias et al. | Elmo: Recursive virtual payment channels for bitcoin | |
CN110730241B (en) | Global scale oriented blockchain infrastructure | |
CN115733841A (en) | Block chain dynamic fragmentation expansion method based on image flow segmentation | |
CN114553662B (en) | Resource allocation method and device for physical layer security of Internet of things through fog | |
Chen | Scaling byzantine fault-tolerant consensus with optimized shading scheme | |
de Cristo et al. | Pub/sub Dissemination on the XRP Ledger | |
CN112398640B (en) | Optimized block chain consensus algorithm | |
KR102405922B1 (en) | Apparatus and method for communicating by hierarchical node grouping in blockchain-based drone swarm system | |
CN115208578A (en) | Unmanned aerial vehicle cluster information consistency sharing method based on block chain |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |