CN111080452B - Hierarchical transaction method suitable for energy block chain - Google Patents
Hierarchical transaction method suitable for energy block chain Download PDFInfo
- Publication number
- CN111080452B CN111080452B CN201911301441.4A CN201911301441A CN111080452B CN 111080452 B CN111080452 B CN 111080452B CN 201911301441 A CN201911301441 A CN 201911301441A CN 111080452 B CN111080452 B CN 111080452B
- Authority
- CN
- China
- Prior art keywords
- transaction
- chain
- sub
- main chain
- main
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 20
- 239000012634 fragment Substances 0.000 claims description 33
- 238000005192 partition Methods 0.000 claims description 23
- 230000000977 initiatory effect Effects 0.000 claims description 4
- 238000010276 construction Methods 0.000 claims description 3
- 238000004806 packaging method and process Methods 0.000 claims description 3
- 238000012856 packing Methods 0.000 claims description 3
- VYMDGNCVAMGZFE-UHFFFAOYSA-N phenylbutazonum Chemical compound O=C1C(CCCC)C(=O)N(C=2C=CC=CC=2)N1C1=CC=CC=C1 VYMDGNCVAMGZFE-UHFFFAOYSA-N 0.000 claims description 3
- 239000003999 initiator Substances 0.000 claims 1
- 230000007246 mechanism Effects 0.000 description 8
- 238000005516 engineering process Methods 0.000 description 5
- 238000010248 power generation Methods 0.000 description 2
- 238000012550 audit Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000002146 bilateral effect Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Classifications
-
- 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
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
- G06F16/278—Data partitioning, e.g. horizontal or vertical partitioning
-
- 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
- G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
- G06Q50/06—Energy or water supply
-
- 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/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- 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/50—Network services
- H04L67/52—Network services specially adapted for the location of the user terminal
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Economics (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Computing Systems (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Marketing (AREA)
- Signal Processing (AREA)
- Finance (AREA)
- Computer Networks & Wireless Communication (AREA)
- Accounting & Taxation (AREA)
- General Health & Medical Sciences (AREA)
- Primary Health Care (AREA)
- Technology Law (AREA)
- Tourism & Hospitality (AREA)
- Human Resources & Organizations (AREA)
- Water Supply & Treatment (AREA)
- Data Mining & Analysis (AREA)
- General Engineering & Computer Science (AREA)
- Medical Informatics (AREA)
- Public Health (AREA)
- Development Economics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The invention provides a layering transaction method suitable for an energy block chain, which is used for dividing a slice according to the geographic position of a participating node; all the participating nodes in a patch area commonly maintain a sub-chain account book, and the participating nodes are energy producers and distributors; virtually setting a shared account for each zone, wherein the sum of the shared accounts is the sum of the accounts of all the participating nodes in the zone; 1 participating nodes of each patch are selected as sub-chain master nodes, and the rest participating nodes are slave nodes; the main chain is formed by the sub-chain main nodes of all the slices, and 1 sub-chain main node is selected from the main chain to be used as the main chain main node; all master nodes together maintain a master ledger. Aiming at the characteristic of the transaction specific to the energy block chain, according to the geographical position distribution characteristic, the billing content is limited in a few nodes with the highest association degree, so that the storage space is greatly saved; the transaction of two layers has better stability, flexibility, simplicity and high practicability.
Description
Technical Field
The invention relates to an energy blockchain technology, in particular to an energy blockchain transaction technology based on layered blockchains.
Background
Energy is the basis of social operation, and energy reform is pushing the development of society. In recent years, renewable energy-based distributed power generation technology has been rapidly developed. Different from the large units, large power plants and large power grids of the traditional power system, the distributed energy source has the characteristics of small scale, large fluctuation, wide distribution and the like. The advantages of distributed energy sources are difficult to fully utilize in the traditional large power grid, and local consumption of distributed power generation is required. Because the transaction of the distributed energy source often has the characteristics of small transaction scale and frequent transaction, the traditional centralized transaction mechanism often considers the transaction of the distributed energy source to be unprofitable, the credit endorsement is refused to be provided, and the transaction of the distributed energy source is urgently required to be a trusted bilateral transaction mechanism.
The blockchain has the characteristics of decentralization, distribution, point-to-point and the like, and the blockchain technology can be used for distributed energy transaction. With the development of blockchain technology, various consensus mechanisms are layered endlessly, such as POW, POS, DPOS, PBFT, RAFT, and the like, and the consensus mechanisms are optimized differently for different application ranges, so that the optimization aims at improving the consensus efficiency as much as possible while solving the problem of the general of the Bayesian.
In the current consensus algorithm, the Paxos algorithm and the Lift algorithm are classical distributed consistency algorithms, and are algorithms with quicker consensus, but the Paxos algorithm and the lift algorithm do not solve the Bayesian problem, malicious nodes in the nodes are not considered, and once the malicious nodes send false messages, the whole system is affected.
The PBFT algorithm can effectively solve the Bayesian problem, can tolerate node failure of not more than (n-1)/3, but the PBFT needs to broadcast for many times, the traffic grows in square along with the increase of the nodes, and the high traffic is intolerable for distributed energy transactions involving a large number of nodes. And, the PBFT consensus mechanism needs nodes to store the total account book information, and occupies a large amount of storage space.
Disclosure of Invention
Aiming at the characteristics of distributed energy transaction, the invention provides a hierarchical transaction method based on geographic positions, which is applicable to distributed energy transaction, based on a PBFT algorithm.
The technical scheme adopted by the invention for solving the technical problems is that a layering transaction method applicable to an energy block chain is characterized by comprising the following steps:
1) Blockchain construction of hierarchical transactions: searching an IP geographic information base of the participating node according to the IP address of the participating node, and dividing the segment according to the geographic position of the participating node; all the participating nodes in a patch commonly maintain a sub-chain account book, the sub-chain account book records all transactions related to the patch, and the participating nodes are energy producers; virtually setting a shared account for each zone, wherein the sum of the shared accounts is the sum of the accounts of all the participating nodes in the zone; 1 participating nodes of each patch are selected as sub-chain master nodes, and the rest participating nodes are slave nodes; the main chain is formed by the sub-chain main nodes of all the slices, and 1 sub-chain main node is selected from the main chain to be used as the main chain main node; all the master nodes commonly maintain a master account book;
2) The client sends a transaction request: after searching the affiliated fragment according to the IP address of the client, the client sends a transaction request to the affiliated sub-chain main node, and the sub-chain main node diffuses the transaction request to the participation points in the fragment through a practical Bayesian fault-tolerant algorithm (PBFT) algorithm;
3) After the PBFT consensus is achieved, the intra-zone reference nodes record the transaction into a transaction pool of the intra-zone reference nodes;
4) When the sub-link billing period arrives, the sub-link master node bills the transaction:
4-1) selecting transactions by the sub-chain master node from own transaction pools according to the time sequence of entering the pools, packaging the selected transaction records into blocks and broadcasting the blocks to all slave nodes in a fragment area; when the block is packed, if the IP address of the opposite side client of the transaction is not in the current block and the cross-region transaction occurs, searching the block according to the IP address of the opposite side client, constructing a virtual transaction which is transferred or out from a shared account in the block by a sub-chain main node according to the cross-region transfer amount on one hand, and packing the virtual transaction into the block after the related transaction record of the virtual transaction; the other side broadcasts a main chain transaction request for generating virtual transaction to all slave nodes in the zone;
4-2) after the blocks broadcast by the sub-chain main nodes reach consensus in the patch area through PBFT, each participating node stores the blocks into a local sub-chain account book; when the cross-region transaction occurs, after the main chain transaction request of the virtual transaction broadcasted by the cross-region transaction is replied by the signature of more than 2/3 slave nodes in the region, the sub-chain master node reconstructs the main chain transaction associated with the virtual transaction and broadcasts the main chain transaction in the main chain; the account of the main chain transaction is a shared account of the region where the sub-chain main node initiating the main chain transaction is located;
5) Backbone collection backbone transactions: after each main chain node receives the broadcasted main chain transaction request, storing the main chain transaction associated with the sub-chain virtual transaction into a transaction pool of the main chain node;
6) When the backbone billing period arrives, the backbone master node bills the collected backbone transaction record: the main chain main node selects main chain transaction according to the time sequence of entering the pool from own transaction pool, packs the selected main chain transaction record into blocks and broadcasts in the main chain; after the blocks broadcast by the main chain main node reach consensus in the main chain through a practical Bayesian fault-tolerant algorithm PBFT, each participating node saves the blocks to a local main chain account book.
The method has the beneficial effects that based on the characteristics of the geographical position areas of the distributed power grid purchase, the accounting content is limited in a few nodes with highest association degree according to the geographical position distribution characteristics aiming at the special transaction of the energy block chain. The storage space is greatly saved; and the transaction network of the two layers can have better stability, the malicious attack is difficult to attack the whole blockchain network, and the method has the characteristics of flexibility, simplicity and high practicability.
Drawings
FIG. 1 is a block chain architecture of the present invention.
FIG. 2 is a block chain architecture of the present invention.
Fig. 3 is a diagram of a transaction process according to the present invention.
Detailed Description
The present invention will be described in further detail with reference to the accompanying drawings and examples. It should not be construed that the scope of the above subject matter of the present invention is limited to the following embodiments, and all techniques realized based on the present invention are within the scope of the present invention.
Referring to fig. 1, the architecture involved in the hierarchical consensus mechanism of the present invention includes the following hierarchies:
1: application layer: the distributed power grid transaction system is used for receiving a distributed power grid transaction request from a client;
2: transaction layer: for the transaction mechanism, synchronous update of the account book is achieved among nodes through a consensus mechanism;
3: storage layer: for the ledger-book storage scheme of the invention, a large number of blocks are stored into different slices through the characteristics of slice storage.
Referring to FIG. 2, the relationship between the consensus machine chain and the main chain according to the present invention is characterized as follows:
1: the device is provided with a plurality of sub-chains (slices), and the nodes among the sub-chains are not overlapped with each other;
2: the sub-chain and the main chain respectively maintain respective account books;
3: the main chain participation node is a sub-chain main node;
4: the accounts in the main chain are shared by the sub-chain sheet areas, and specific account information is recorded in the sub-chains.
The specific implementation method is shown in fig. 3:
1) Blockchain construction of hierarchical transactions: searching an IP geographic information base of the participating node according to the IP address of the participating node, and dividing the segment according to the geographic position of the participating node; all the participating nodes in a patch commonly maintain a sub-chain account book, the sub-chain account book records all transactions related to the patch, and the participating nodes are energy producers; virtually setting a shared account for each zone, wherein the sum of the shared accounts is the sum of the accounts of all the participating nodes in the zone; 1 participating nodes of each patch are selected as sub-chain master nodes, and the rest participating nodes are slave nodes; the main chain is formed by the sub-chain main nodes of all the slices, and 1 sub-chain main node is selected from the main chain to be used as the main chain main node; all the master nodes commonly maintain a master account book; when the nodes in the patch area change, the sub-chain main nodes broadcast the node change to the main chain;
2) The client sends a transaction request: after searching the affiliated fragment according to the IP address of the client, the client sends the generated transaction request to the affiliated fragment master node; the client can inquire the basic information of the participating nodes of the main chain and other sub-chains (fragments) from the sub-chain main node of the client, wherein the basic information comprises a public key, an IP address and the like;
3) Nodes in the patch collect transactions for clients: the intra-patch reference nodes and the intra-patch reference nodes are in consensus with each other through a PBFT algorithm, and the transaction is stored in a transaction pool maintained by the own node;
4) When the sub-link billing period arrives, the sub-link master node bills the transaction:
4-1) selecting transactions by the sub-chain master node from own transaction pools according to the time sequence of entering the pools, packaging the selected transaction records into blocks and broadcasting the blocks to all slave nodes in a fragment area; when the block is packed, if the IP address of the opposite side client of the transaction is not in the current block and the cross-region transaction occurs, searching the block according to the IP address of the opposite side client, constructing a virtual transaction which is transferred or out from a shared account in the block by a sub-chain main node according to the cross-region transfer amount on one hand, and packing the virtual transaction into the block after the related transaction record of the virtual transaction; the other side broadcasts a main chain transaction request for generating virtual transaction to all slave nodes in the zone;
4-2) after the blocks broadcasted by the sub-chain main nodes reach consensus in the patch area through a practical Bayesian fault-tolerant algorithm PBFT, each participating node stores the blocks into a local sub-chain account book; when the cross-region transaction occurs, after the main chain transaction request of the virtual transaction broadcasted by the cross-region transaction is replied by the signature of more than 2/3 slave nodes in the region, the sub-chain master node reconstructs the main chain transaction associated with the virtual transaction and broadcasts the main chain transaction in the main chain; the account of the main chain transaction is a shared account of the region where the sub-chain main node initiating the main chain transaction is located;
5) Backbone collection backbone transactions: after each main chain node receives the broadcasted main chain transaction request, storing the main chain transaction associated with the sub-chain virtual transaction into a transaction pool of the main chain node;
6) When the backbone billing period arrives, the backbone master node bills the collected backbone transaction record: the main chain main node selects main chain transaction according to the time sequence of entering the pool from own transaction pool, packs the selected main chain transaction record into blocks and broadcasts in the main chain; after the blocks broadcast by the main chain main node reach consensus in the main chain through a practical Bayesian fault-tolerant algorithm PBFT, each participating node saves the blocks to a local main chain account book.
7) A client side inquiring step:
when the client side inquires the transaction in the fragment:
7-1) the client broadcasts a transaction inquiry request to the region where the client is located;
7-2) after receiving the transaction inquiry request, the participating node in the segment searches whether the transaction record is stored in the local sub-chain account book, if so, signs the inquiry result and returns the inquiry result to the client, if not, returns the inquiry failure to the client;
7-3) the client receives signature query results of more than 2/3 of the number of the participating nodes in the patch area, and the transaction is considered to be successful.
When the client inquires the cross-zone transaction:
7-1) the client broadcasts a transaction inquiry request to the region where the client is located;
7-2) after receiving the transaction inquiry request, the participating nodes in the segment search whether the transaction record is stored in the local sub-chain account book; if yes, and the transaction record is found to be associated with virtual transaction, returning a signed intra-home transaction inquiry result and the virtual transaction from the node to the client;
7-3) broadcasting a main chain transaction inquiry request to the main chain by a sub-chain main node of the client, searching whether a main chain transaction record is stored in a local main chain account book after the main chain transaction inquiry request is received by a participating node in the main chain, and if so, returning a signed main chain transaction inquiry result;
7-4) forwarding the signed main chain transaction inquiry result returned by the participating node in the main chain to the client by the sub-chain main node of the client; after receiving a main chain transaction inquiry result of a signature with the number of main chain participation nodes being more than 2/3, the sub-chain main node sends a fragment transaction inquiry request to a sub-chain main node of a fragment where the opposite client is located;
7-5) broadcasting the fragment transaction inquiry request in the fragment after receiving the fragment transaction inquiry request by the sub-chain master node of the opposite side client; after receiving the fragment transaction inquiry request, the participating node in the fragment searches whether the local sub-chain account book stores the transaction record, if so, returns a signature inquiry result and virtual transaction to the sub-chain master node; after receiving signature query results and virtual transactions of which the number of the participating nodes in the fragment is more than 2/3, the opposite client forwards the signature query results and the virtual transactions to a sub-chain master node of the client; the sub-chain main node of the client forwards the signature inquiry result and the virtual transaction from the other fragment to the client;
7-6) the client judges whether the returned intra-segment transaction inquiry result and virtual transaction with the number of the participation nodes being more than 2/3 in the segment, the main chain transaction inquiry result with the signature with the number of the main chain participation nodes being more than 2/3 and the signature inquiry result and virtual transaction with the number of the participation nodes being more than 2/3 in the segment where the counterpart client is located are received within the set time, if so, the transaction is considered to be successful, otherwise, the transaction is considered to be unsuccessful.
The inventive solution relates to two hash values hash. One type is block hash in the universal blockchain technique: the hash value of all transactions packed by the whole block is used for marking one block, the other type is transaction hash, and the hash operation is performed on transaction parameters, namely only marking one transaction.
Specifically, when the client generates a transaction request, the sub-chain master node generates a hash when generating a virtual transaction, a main chain transaction request and a main chain transaction, and the hash value is used for corresponding to the transaction by using the identity of both sides of the transaction, the timestamp, the transaction amount and the digital signature of the transaction initiating terminal;
storing a hash of a transaction request generated by a client in a block of the virtual transaction; the method for associating the main chain transaction with the virtual transaction is that the hash of the sub-chain main node in the virtual transaction is stored in a block of the main chain transaction; when a sub-chain main node of the client broadcasts a main chain transaction inquiry request to a main chain, the main chain transaction inquiry request comprises a hash of the main chain transaction; the sub-chain master node of the client sends a fragment transaction inquiry request to the sub-chain master node of the opposite client, wherein the fragment transaction inquiry request comprises a hash corresponding to the main chain transaction.
A typical client transaction request goes through the following process:
1: the client sends a transaction request to the master node, and each participating node agrees through a PBFT process, and each participating node puts the transaction into each transaction pool of the nodes after the agreement.
2. After the PBFT process is achieved, the main node returns a result to the client, and the client saves the transaction hash for checking.
3: after the accounting period starts, the master node grabs a plurality of transactions from the transaction pool, packages the transactions into blocks, adds information such as time stamps, abstracts, current participating nodes and the like into the blocks, sends the blocks to the slave nodes, and the participating nodes reach consensus through PBFT;
4. all nodes save the blocks in a local ledger
5: the client asynchronously verifies whether the transaction is packed into the block through the transaction hash audit.
Example 1
A process that does not involve a cross-zone transaction: suppose that clients A, B are all in tile one, transferring from A to B.
1. Firstly, a client A, B sends a transaction request after each signature to a master node of a fragment;
2. after receiving the transaction request, the master node of the fragment area A agrees with the PBFT to place the transaction into a transaction pool;
3. after the next accounting period is reached, the master node of the partition packs the transaction into a block, and stores the block into a sub-chain account book maintained by each participating node in the partition through PBFT consensus;
4. the client A, B inquires about the transaction from the first region;
5. each participating node of the first fragment finds the transaction from the sub-chain account book, does not relate to the cross fragment, and returns a query result;
6. the client A, B verifies that the transaction was successful by receiving the query result for tile one.
Example 2
One scenario involves a cross-patch transaction, A in patch one, B in patch two, A transfers to B.
1. The client A, B signs the transaction request and sends the transaction request to the master nodes of the first and second slices;
2. after receiving the transaction request, the primary nodes of the first and second sections reach consensus through all the participation nodes of the PBFT and are put into respective transaction pools;
3. after the next accounting period is reached, the first and second sections find that both sides of the transaction relate to trans-regional transaction, virtual transaction is constructed, the first section A account is transferred into the shared account for transaction, the second section B account obtains balance transaction from the shared account, and the virtual transaction is related to actual transaction;
4. and counting transfer total amount of the first and second sections to construct a main chain transaction, specifically, counting all the transactions related to transfer with the second section by a main node of the first section, subtracting the total amount of the second section transferred to the first section from the total amount of the first section transferred to the second section, calculating the amount of the transfer required to be transferred from a shared account, constructing a first section transferred to the second section transaction request, and associating virtual transactions in a sub-chain, wherein the association method is to package virtual transaction hashes of the first section to the second section into the main chain transaction request. The master node sends the main chain transaction request to all nodes, the nodes verify and sign the main chain transaction request, and the master node and most slave nodes in the patch sign and then send the signed request to the main chain;
5. after the main chain node receives the main chain request, the transaction is put into a main chain transaction pool;
6. after the main chain billing period is reached, the main chain firstly records the current block hash of each fragment into a block header, and then packages main chain transaction and associated virtual transaction;
7. the client A searches the transaction, firstly, a query request is sent to the first fragment, after the first fragment receives the search request, the first fragment searches and finds out that the transaction is a virtual transaction, the virtual transaction is illustrated as a cross-chain transaction, and a query result is returned;
8. the master node in the first fragment sends a query request to the main chain, and the main chain searches actual cross-chain transaction according to the virtual transaction and returns a query result;
9. the master node of the first fragment finds out that the purpose of the cross-chain transaction is a second fragment, sends a query request to the second fragment, searches out the associated virtual transaction through the main chain transaction, and returns a query result;
10. the client A verifies whether the whole transaction is successful or not through the query results of the first and second sections and the query result of the main chain transaction.
Claims (2)
1. A hierarchical transaction method applicable to an energy blockchain, comprising the steps of:
1) Blockchain construction of hierarchical transactions: searching an IP geographic information base of the participating node according to the IP address of the participating node, and dividing the segment according to the geographic position of the participating node; all the participating nodes in a patch commonly maintain a sub-chain account book, the sub-chain account book records all transactions related to the patch, and the participating nodes are energy producers; virtually setting a shared account for each zone, wherein the sum of the shared accounts is the sum of the accounts of all the participating nodes in the zone; 1 participating nodes of each patch are selected as sub-chain master nodes, and the rest participating nodes are slave nodes; the main chain is formed by the sub-chain main nodes of all the slices, and 1 sub-chain main node is selected from the main chain to be used as the main chain main node; all the master nodes commonly maintain a master account book;
2) The client sends a transaction request: after searching the affiliated fragment according to the IP address of the client, the client sends a transaction request to the affiliated sub-chain main node, and the sub-chain main node diffuses the transaction request to the participation points in the fragment through a practical Bayesian fault-tolerant algorithm;
3) The intra-zone reference and the node record the transaction into a transaction pool after the co-identification of the transaction is achieved through a practical Bayesian fault-tolerant algorithm;
4) When the sub-link billing period arrives, the sub-link master node bills the transaction:
4-1) selecting transactions by the sub-chain master node from own transaction pools according to the time sequence of entering the pools, packaging the selected transaction records into blocks and broadcasting the blocks to all the slave nodes of the subareas; when the block is packed, if the IP address of the opposite side client side of the transaction is not in the current partition and the cross-region transaction occurs, searching the partition according to the IP address of the opposite side client side, constructing a virtual transaction which is transferred in or out from a shared account in the block by the sub-chain master node according to the cross-region transfer amount on one hand, and packing the virtual transaction into the block after the related transaction record of the virtual transaction; the other side broadcasts a main chain transaction request for generating virtual transaction to all slave nodes in the partition;
4-2) after the blocks broadcasted by the sub-chain main nodes reach consensus in the patch area through a practical Bayesian fault-tolerant algorithm, each participating node stores the blocks into a local sub-chain account book; when the cross-region transaction occurs, after the main chain transaction request of the virtual transaction broadcasted by the cross-region transaction is replied by the signature of more than 2/3 slave nodes in the region, the sub-chain master node reconstructs the main chain transaction associated with the virtual transaction and broadcasts the main chain transaction in the main chain; the account of the main chain transaction is a shared account of the region where the sub-chain main node initiating the main chain transaction is located;
5) Backbone collection backbone transactions: after each main chain node receives the broadcasted main chain transaction request, storing the main chain transaction associated with the sub-chain virtual transaction into a transaction pool of the main chain node;
6) When the backbone billing period arrives, the backbone master node bills the collected backbone transaction record: the main chain main node selects main chain transaction according to the time sequence of entering the pool from own transaction pool, packs the selected main chain transaction record into blocks and broadcasts in the main chain; after the block broadcasted by the main chain main node reaches consensus in the main chain through a practical Bayesian-busy fault-tolerant algorithm, each participating node stores the block into a local main chain account book;
7) A client side inquiring step:
7-1) the steps when the client queries the transaction within the tile include:
7-1-1) the client broadcasts a transaction inquiry request to the partition where the client is located;
7-1-2) after receiving the transaction inquiry request, searching whether the transaction record is stored in the local sub-chain account book, if so, signing the inquiry result and returning to the client, if not, returning to the inquiry and losing to the client;
7-1-3) the client receives signature query results of more than 2/3 of the number of the participating nodes in the partition, and considers that the transaction is successful;
7-2) the step of querying the trans-regional transaction when the client comprises:
7-2-1) the client broadcasting a transaction query request to the partition where it is located;
7-2-2) after receiving the transaction inquiry request, searching whether the transaction record is stored in the local sub-chain account book; if yes, and the transaction record is found to be associated with virtual transaction, returning a signed transaction inquiry result and virtual transaction in the partition from the node to the client;
7-2-3) broadcasting a main chain transaction inquiry request to a main chain by a sub-chain main node of the client, searching whether a main chain transaction record is stored in a local main chain account book after a participation node in the main chain receives the main chain transaction inquiry request, and if so, returning a signed main chain transaction inquiry result;
7-2-4) the sub-chain master node of the client forwards the signed main chain transaction query result returned by the participating node in the main chain to the client; after receiving a main chain transaction inquiry result of a signature with the number of main chain participation nodes being more than 2/3, the sub-chain main node sends a partition transaction inquiry request to a sub-chain main node of a partition where the opposite client is located;
7-2-5) broadcasting the partition transaction inquiry request in the partition after receiving the partition transaction inquiry request by the sub-chain master node of the opposite side client; after receiving the partition transaction inquiry request, the participating nodes in the partition find out whether the local sub-chain account book stores the transaction record, if so, the participating nodes return signature inquiry results and virtual transactions to the sub-chain master node; after receiving signature query results and virtual transactions of more than 2/3 of the number of the participating nodes in the partition, the opposite client forwards the signature query results and the virtual transactions to a sub-chain master node of the client; the sub-chain main node of the client forwards the signature query result and the virtual transaction from the other partition to the client;
7-2-6) the client judges whether the transaction inquiry result and the virtual transaction in the partition with the number of the participation nodes being more than 2/3 in the returned partition, the main chain transaction inquiry result of the signature with the number of the participation nodes being more than 2/3 in the main chain and the signature inquiry result and the virtual transaction with the number of the participation nodes being more than 2/3 in the partition where the other client is located are received within the set time, if yes, the transaction is considered to be successful, otherwise, the transaction is considered to be unsuccessful.
2. The method of claim 1, wherein the client generates a hash value when generating the transaction request, when generating the virtual transaction, the main-chain transaction request and the main-chain transaction, and the hash value is used for corresponding to the transaction by using the identity of both sides of the transaction, the timestamp, the transaction amount and the digital signature of the transaction initiator;
storing a hash value of a transaction request generated by a client in a block of the virtual transaction;
the method for associating the main chain transaction with the virtual transaction is that the hash value of the sub-chain master node in the virtual transaction is stored in a block of the main chain transaction;
when a sub-chain main node of a client broadcasts a main chain transaction inquiry request to a main chain, the main chain transaction inquiry request comprises a hash value of the main chain transaction;
the sub-chain master node of the client sends a partition transaction inquiry request to the sub-chain master node of the opposite client, wherein the partition transaction inquiry request comprises a hash value corresponding to the main chain transaction.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911301441.4A CN111080452B (en) | 2019-12-17 | 2019-12-17 | Hierarchical transaction method suitable for energy block chain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911301441.4A CN111080452B (en) | 2019-12-17 | 2019-12-17 | Hierarchical transaction method suitable for energy block chain |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111080452A CN111080452A (en) | 2020-04-28 |
| CN111080452B true CN111080452B (en) | 2023-12-29 |
Family
ID=70315023
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911301441.4A Active CN111080452B (en) | 2019-12-17 | 2019-12-17 | Hierarchical transaction method suitable for energy block chain |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111080452B (en) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111680050B (en) * | 2020-05-25 | 2023-09-26 | 杭州趣链科技有限公司 | Fragment processing method, device and storage medium for alliance chain data |
| CN113742417B (en) * | 2020-05-29 | 2024-06-07 | 同方威视技术股份有限公司 | Multistage distributed consensus method and system, electronic equipment and computer readable medium |
| CN112788139B (en) * | 2021-01-12 | 2022-11-18 | 北京工业大学 | Block chain storage capacity optimization method and system |
| CN113095940B (en) * | 2021-04-29 | 2024-05-10 | 平安科技（深圳）有限公司 | Isomorphic multi-chain based transaction processing method, blockchain system, equipment and medium |
| CN113259453B (en) * | 2021-06-02 | 2021-10-15 | 支付宝(杭州)信息技术有限公司 | Cross-chain interaction method and device |
| CN113259460B (en) * | 2021-06-02 | 2021-10-15 | 支付宝(杭州)信息技术有限公司 | Cross-chain interaction method and device |
| CN113922971B (en) * | 2021-06-02 | 2023-10-27 | 支付宝(杭州)信息技术有限公司 | Cross-chain interaction method and device |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105809420A (en) * | 2016-03-08 | 2016-07-27 | 杭州复杂美科技有限公司 | Liquidation method of multi-layer block chain |
| CN107147735A (en) * | 2017-05-12 | 2017-09-08 | 北京博晨技术有限公司 | A kind of distributed account book system based on hierarchy |
| CN108616596A (en) * | 2018-05-09 | 2018-10-02 | 南京邮电大学 | It is adaptively known together method based on the block chain that dynamic authorization and network environment perceive |
| CN108900321A (en) * | 2018-06-06 | 2018-11-27 | 广州链块科技有限公司 | The method that a kind of block chain by stages carries out real-time atom transaction |
| CN108960823A (en) * | 2018-03-30 | 2018-12-07 | 杭州复杂美科技有限公司 | A kind of block chain multichain concurrent transaction system |
| CN109462587A (en) * | 2018-11-09 | 2019-03-12 | 四川虹微技术有限公司 | Block chain is layered common recognition method, block chain network system and block chain node |
| KR20190086298A (en) * | 2018-01-12 | 2019-07-22 | 인제대학교 산학협력단 | Involvement Control System of Block Chain Controller based on Transaction Value |
| CN110570202A (en) * | 2019-09-02 | 2019-12-13 | 杭州趣链科技有限公司 | Hybrid consensus method based on fragmentation technology |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20190251199A1 (en) * | 2018-02-14 | 2019-08-15 | Ivan Klianev | Transactions Across Blockchain Networks |
| US20190354518A1 (en) * | 2018-05-01 | 2019-11-21 | Michael Zochowski | Chain mesh network for decentralized transaction systems |
-
2019
- 2019-12-17 CN CN201911301441.4A patent/CN111080452B/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105809420A (en) * | 2016-03-08 | 2016-07-27 | 杭州复杂美科技有限公司 | Liquidation method of multi-layer block chain |
| CN107147735A (en) * | 2017-05-12 | 2017-09-08 | 北京博晨技术有限公司 | A kind of distributed account book system based on hierarchy |
| KR20190086298A (en) * | 2018-01-12 | 2019-07-22 | 인제대학교 산학협력단 | Involvement Control System of Block Chain Controller based on Transaction Value |
| CN108960823A (en) * | 2018-03-30 | 2018-12-07 | 杭州复杂美科技有限公司 | A kind of block chain multichain concurrent transaction system |
| CN108616596A (en) * | 2018-05-09 | 2018-10-02 | 南京邮电大学 | It is adaptively known together method based on the block chain that dynamic authorization and network environment perceive |
| CN108900321A (en) * | 2018-06-06 | 2018-11-27 | 广州链块科技有限公司 | The method that a kind of block chain by stages carries out real-time atom transaction |
| CN109462587A (en) * | 2018-11-09 | 2019-03-12 | 四川虹微技术有限公司 | Block chain is layered common recognition method, block chain network system and block chain node |
| CN110570202A (en) * | 2019-09-02 | 2019-12-13 | 杭州趣链科技有限公司 | Hybrid consensus method based on fragmentation technology |
Non-Patent Citations (1)
| Title |
|---|
| 区块链智能合约技术在金融领域的研发应用现状、问题及建议;刘德林;;海南金融(第10期);27-31 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111080452A (en) | 2020-04-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111080452B (en) | Hierarchical transaction method suitable for energy block chain | |
| CN110493148B (en) | Block processing, block consensus and block synchronization method and device | |
| CN110945853A (en) | Method for generating and managing multimode identification network based on alliance chain voting consensus algorithm | |
| US20100110935A1 (en) | Efficient Content Authentication In Peer-To-Peer Networks | |
| CN114391241B (en) | Blockchain sharding with adjustable quorum | |
| CN111369319B (en) | Crowd-sourced logistics dispatching and scheduling system and method based on blockchain | |
| Kamil et al. | A big data anonymous batch verification scheme with conditional privacy preservation for power injection over vehicular network and 5G smart grid slice | |
| Li et al. | Achieving scalability and load balance across blockchain shards for state sharding | |
| Li et al. | Scalable blockchain storage mechanism based on two-layer structure and improved distributed consensus | |
| CN101242365B (en) | Peer network secure routing method based on multi-dimension distributed hash table | |
| CN113448694A (en) | Block chain consensus method for improving transaction processing capability | |
| CN111080298B (en) | Block generation and transaction verification method suitable for energy block chain | |
| CN116963077A (en) | Block chain slicing method for spectrum transaction | |
| Xi et al. | [Retracted] A Comprehensive Survey on Sharding in Blockchains | |
| Miglani et al. | Blockchain-based co-operative caching for secure content delivery in CCN-enabled V2G networks | |
| WO2009100636A1 (en) | A method and device for the storage management of the user data in the telecommunication network | |
| Wang et al. | Enhancing power grid resilience with blockchain-enabled vehicle-to-vehicle energy trading in renewable energy integration | |
| CN116258609B (en) | Electric power system transaction cooperation method, device and storage medium | |
| CN116260826A (en) | Bayesian-busy fault tolerance consensus method and system in supply chain tracing | |
| CN115689760B (en) | Block chain fragmentation consensus method, device and equipment for high concurrent power transaction | |
| CN114499874B (en) | Bayesian-busy-family fault-tolerant consensus optimization method applied to industrial Internet | |
| Li et al. | EBFT: A hierarchical and group-based byzantine fault tolerant consensus algorithm | |
| CN115733841A (en) | Block chain dynamic fragmentation expansion method based on image flow segmentation | |
| Furness et al. | Considering complex search techniques in DHTs under churn | |
| Wang et al. | A green power traceability technology based on timestamp in a main-side chain system |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |