POWER TRANSACTION DATA STORAGE SYSTEM BASED ON PRIVATE BLOCKCHAIN PLATFORM AND METHOD FOR VERIFYING AND DISTRIBUTEDLY STORING POWER TRANSACTION DATA USING THE SAME

Abstract

Provided is a method for effectively distributedly storing and verifying power transaction major data such as bidding, matching, and calculation that takes place as prosumers and consumers participate in an energy transaction service in a private blockchain platform-based peer-to-peer (P2P) network environment. By applying a distributed ledger technology for storing and verifying reliable power transaction data by securing a consensus algorithm and a chaincode of a private blockchain, reliability of a power transaction service between energy market participants may be increased and an added value of reducing transaction costs may be created.

Claims

1. A power transaction data storage system based on blockchain, wherein a transaction is generated for power transaction data related to bidding, matching, and calculation in an energy transaction service based on hyperledger fabric blockchain network, and verified by executing a chaincode.

2. The power transaction data storage system of claim 1, comprising: a bidding module transmitting a transaction including the power transaction data information to the Hyperledger Fabric blockchain network; a matching module providing matching information for concluding a transaction between customers including a prosumer and a consumer; and a calculation module calculating a benefit for each customer based on the matching information.

3. A method for verifying and distributedly storing power transaction data based on blockchain to mediate a power transaction between a prosumer and a consumer using the power transaction data storage system of claim 1, the method comprising: a bidding operation in which the bidding module receives a desired transaction price and a transaction volume from the prosumer or the consumer, proposes an expected benefit to the prosumer or the consumer, creates a bidding transaction, and transmits the created bidding transaction to a blockchain; a matching operation in which the matching module creates a matching transaction using a bidding quantity and a bidding price bidden by the prosumer or the consumer and transmits the created matching transaction to the blockchain to store the transaction; and a calculating operation in which the calculation module executes calculation for a final charge, a benefit for transaction details of the prosumer and the consumer, creates a calculation transaction, and then transmits the created transaction to the blockchain to store the transaction.

4. The method of claim 3, wherein, the bidding operation includes an expected benefit operation of receiving a desired power transaction quantity from the prosumer or the consumer using surplus power generation quantity and a supply quantity of the prosumer and the consumer for each time zone and calling an expected benefit module to execute an expected benefit logic.

5. A method for verifying and distributedly storing power transaction data based on blockchain to mediate a power transaction between a prosumer and a consumer using the power transaction data storage system of claim 2, the method comprising: a bidding operation in which the bidding module receives a desired transaction price and a transaction volume from the prosumer or the consumer, proposes an expected benefit to the prosumer or the consumer, creates a bidding transaction, and transmits the created bidding transaction to a blockchain; a matching operation in which the matching module creates a matching transaction using a bidding quantity and a bidding price bidden by the prosumer or the consumer and transmits the created matching transaction to the blockchain to store the transaction; and a calculating operation in which the calculation module executes calculation for a final charge, a benefit for transaction details of the prosumer and the consumer, creates a calculation transaction, and then transmits the created transaction to the blockchain to store the transaction.

6. The method of claim 5, wherein, the bidding operation includes an expected benefit operation of receiving a desired power transaction quantity from the prosumer or the consumer using surplus power generation quantity and a supply quantity of the prosumer and the consumer for each time zone and calling an expected benefit module to execute an expected benefit logic.

Description

DESCRIPTION OF DRAWINGS

[0022] FIG. 1 is a conceptual diagram of a hyperledger fabric blockchain network structure.

[0023] FIG. 2 is a conceptual diagram of a power transaction system based on hyperledger fabric blockchain.

[0024] FIG. 3 is a transaction procedure diagram for storing power transaction data.

[0025] FIG. 4 is a block diagram of a chaincode for storing power transaction data.

BEST MODES

[0026] Technical terms used in this specification are used to merely illustrate specific embodiments, and should be understood that they are not intended to limit the present disclosure.

[0027] As far as not being defined differently, all terms used herein including technical or scientific terms may have the same meaning as those generally understood by an ordinary person skilled in the art to which the present disclosure pertains, and should not be construed in an excessively comprehensive meaning or an excessively restricted meaning.

[0028] In addition, general terms used in the description of the present disclosure should be construed according to definitions in dictionaries or according to its front or rear context, and should not be construed to have an excessively restrained meaning.

[0029] However, it is to be understood that the present invention is not limited to a specific disclosed form and various combinations may be made within the embodiments unless mentioned otherwise or as long as there is no contradiction therebetween.

[0030] In describing the present invention, if it is determined that a detailed description of known techniques associated with the present invention unnecessarily obscures the gist of the present invention, the detailed description thereof will be omitted.

[0031] In addition, it should be noted that the accompanying drawings are only for easy understanding of the spirit of the present invention, and should not be construed as limiting the spirit of the present invention by the accompanying drawings.

[0032] A prosumer refers to a person who may produce power through a small-scale power generation (e.g., solar power, wind power, etc.) and also may consume power, in addition to an existing power producer who produces power through an infrastructure (e.g., thermal power plant, nuclear power plant, hydroelectric power plant, etc.). As prosumers emerge, power transactions between individuals are required, and energy loss may be minimized by power supply through exchanging information on power demand and power supply in real time between energy prosumers . However, there is no environment in which individual prosumers conduct autonomous transactions without relying on a central trusted institution and safely store and verify power transaction data.

[0033] A commonly used blockchain technology corresponds to a public blockchain (Public Blockchain). In the case of a public blockchain, anyone may participate in a network and perform roles such as read, verification, and transaction 400 generation. In addition, since the public blockchain uses a consensus algorithm 300 that allows partial branches, a processing rate is also very slow.

[0034] In contrast, hyperledger fabric blockchain, which is a private blockchain, may limit network participation using a membership function. Therefore, only an authenticated user is responsible for verification, transaction 400 generation, and the like. The consensus algorithm 300 also has an advantage in that a processing rate is high using a fast RAFT-based algorithm without allowing partial branches.

[0035] FIG. 1 is a conceptual diagram of the hyperledger fabric blockchain network 100 structure of the present disclosure. Hyperledger Fabric is a worldwide open-source platform organized for the development of inter-industry blockchain technology. Hyperledger Fabric is a private blockchain, allowing only authenticated users to record transaction history on a P2P network and also record execution history using a chaincode 132.

[0036] As shown in the structure of the private Hyperledger Fabric illustrated in FIG. 1, nodes constituting the hyperledger fabric blockchain include an orderer 110 node, a certificate authority (CA) 120 node, and a peer 130 node. The orderer node is responsible for ordering a transaction 400 by the consensus algorithm 300 and creating a block with a sorted transaction 400. The CA node checks an identity of members participating in the hyperledger fabric blockchain network 100 and manages their authority. The peer node is responsible for maintaining the hyperledger fabric blockchain network 100, processing proposals and responses of the transaction 400, and managing a ledger 131 and a chaincode 132.

[0037] Next, the channel 200 is a communication mechanism between groups within a consortium, which is very important in hyperledger fabric. The channel 200 enables data separation and confidentiality, and channel 200 configuration information contains all information necessary for an operation of the channel 200, such as authority information of the peer 130 that may access the channel 200.

[0038] FIG. 2 is a conceptual diagram of an energy transaction system. In a process to be performed by a user and the system with respect to the bidding 510, matching 520, and calculation 530 corresponding to main functions when operating the energy transaction service 500, the transaction 400 is created for power data such as energy transaction bidding 510, matching 520, and calculation 530, and transmitted to a private blockchain network to distribute and store power data.

[0039] When the prosumer or consumer inputs a desired transaction price and a transaction volume, the system derives a price range boundary section through a fee module to derive an expected benefit 511 in which both the prosumer and the consumer benefit.

[0040] The bidding 510 is executed through power sales and purchase information prepared by a customer based on the provided expected benefit 511.

[0041] The matching 520 is performed by inquiring about a bid quantity and a bid price bid by a prosumer or a consumer and prioritizing sales and purchase prices based on the bid information.

[0042] The calculation 530 for transaction details based on the bidding details participated by the customer is derived and a calculation quantity is distributed to each participant.

[0043] FIG. 3 is a process diagram of the transaction 400 for storing power transaction data of the present disclosure. To make an energy transaction, an energy prosumer or consumer creates a power transaction data storage transaction 400 and transmits the transaction 400 to all peer 130 nodes. All peer 130 nodes execute the chaincode 132 according to a power transaction data storage guarantee policy to verify the transaction 400 and perform simulation.

[0044] If a simulation result value satisfies the power transaction data storage guarantee policy, the result value is transmitted to an ordering service 111. The orderer 110 arranges the transaction 400 in order and creates a block and transmits the block to all peer 130 nodes, and all peer 130 nodes determine whether the received block satisfies the guarantee policy, adds a new block, and updates a state of the ledger 131.

[0045] FIG. 4 is a block diagram of the chaincode 132 for storing the power transaction data of the present disclosure. Chaincode 132 implements contract conditions or rules as business logic so that processing may always be performed according to the agreed rules, stores the latest state of data in a key-value store (KVS) 133 and is executed by the implemented business logic. In the present disclosure, by implementing power transaction data storage business logic of the energy transaction bidding 510, matching 520, and calculation 530 of the chaincode 132, the latest power transaction data is stored in the KVS 133 and power transaction data storage history is added as a block.

TABLE-US-00001 TABLE 1 Method Function Class name Method name description description BiddingChaincode getBiddingInfo Inquire about Inquire about bidding bidding information information InsertBidding Register Bidding Register bidding information information such as bid quantity, bid price, etc. updateBidding Correct Bidding Correct information registered bidding information MatchingChaincode GetMatchingInfo Inquire about Inquire about matching matching information information between seller-buyer insertMatching Register Register matching transaction information settlement information such as contract quantity, contract price, etc. updateMatching Correct matching Correct information registered matching information CalculationChaincode getCalculationInfo Inquire about Inquire about calculation calculation information information of each customer insertCalculation Register Register calculation calculation information information such as calculation quantity, benefit, etc. updateCalculation Correct Correct calculation registered information calculation information

[0046] Table 1 shows the chaincode 132 for each type of energy transaction, in which power transaction data is classified, the name of the JAVA-side actual method (function) to be performed, name of actual method (function) of JAVA side to perform, parameter, type, return type, and performing contents are shown, and a process of calling each power transaction data storage chaincode 132 in an energy transaction service 500 is shown.

TABLE-US-00002 TABLE 2 Data type Classification Column name Column description Index Calculation CUST_ID Customer ID Character Y string CALCULATION_YM Calculation Character Y year month string CALCULATION_TYPE_CD Calculation Character type code string SUPPLY_QTY Supply Number quantity (integer) GEN_QTY Surplus Number generation (integer) quantity BEFORE_CAL_QTY Calculation Number quantity (integer) before transaction BEFORE_CHARGE Electric Number charge (integer) before transaction AFTER_CAL_QTY Calculation Number quantity (integer) after transaction AFTER_CHARGE Electric Number charge after (integer) transaction REVENUE_EXPENSE Sales Number revenue (integer) FINAL_CHARGE Final charge Number (integer) BENEFIT Benefit Number (integer) Bidding CUST_ID Customer ID Character Y string BIDDING_YM Bidding year Character Y month string BIDDING_TIMESTAMP Bidding time Character stamp string BIDDING_TYPE_CD Bidding type Character code string DESIRE_PRICE Desired Number selling or (integer) purchasing price DESIRE_QTY Desired Number selling or (integer) purchasing quantity EXP_BENEFIT Expected Number benefit (integer) LIMIT_PRICE Selling Number upper limit (integer) or purchase lower limit Matching CONTRACT_TYM Contract Character Y year month string SALE_USER_ID Seller ID Character Y string BUY_USER_ID Buyer ID Character Y string CONTRACT_QTY Contract Number quantity (integer) CONTRACT_PRICE Contract Number price (integer) CONTRACT_STATE_CD Contract Character state code string

[0047] Table 2 is a schema data structure for recording actual power transaction data in the KVS 133, and main data of power transaction in the bidding 510, matching 520, and calculation 530 of the energy transaction service 500 are distributedly stored in a block to secure reliability and guarantee data transparency.

[0048] Although preferred embodiments according to the present disclosure have been described above, the present disclosure is not limited thereto, and should be interpreted by those skilled in the art to which the present invention pertains to encompass various variations without departing from the gist of the present invention appended in the claims. The claims are intended to cover such variations.

DESCRIPTION OF REFERENCE NUMERALS

[0049] 100: hyperledger fabric blockchain network

[0050] 110: orderer

[0051] 111: orderer Service

[0052] 120: CA (Certificate Authority)

[0053] 130: peer

[0054] 131: ledger

[0055] 132: chaincode

[0056] 133: KVS (Key-Value Store)

[0057] 200: channel

[0058] 300: consensus algorithm

[0059] 400: transaction

[0060] 500: energy transaction service

[0061] 510: bidding

[0062] 511: expected benefit

[0063] 520: matching

[0064] 530: calculation