KR20200065662A - P2p energy transaction platform using hyperledger - Google Patents

Abstract

The present invention relates to a P2P energy transaction platform using hyperledger. An objective of the present invention is to propose the energy transaction platform adopting blockchain, which is a transparent, distributed, and secure transaction log recording method.

Description

P2P energy trading platform using hyper leisure {P2P ENERGY TRANSACTION PLATFORM USING HYPERLEDGER}

The present invention relates to a P2P energy trading platform.

In addition to the reduction of greenhouse gas emissions in accordance with the recent agreement on the new climate system, the government is implementing a de-nuclear power policy, so the development of a new and renewable energy business is essential, and an individual is a prosumer who produces and consumes electricity by itself, such as solar light. Is increasing.

The present invention introduces a distributed power source to efficiently operate renewable energy, and at the same time, it is energy efficient to sell to neighboring consumers when the quantity of production remains according to the production and consumption patterns and purchase in case of shortage, and guarantee profits to the public. The goal is to propose an energy trading platform that introduces a blockchain that is a transparent, decentralized, and secure transaction log recording method that allows complete and continuous tracking of even very small energy transactions.

P2P energy trading platform using hyper leisure.

The present invention introduces a distributed power source to efficiently operate renewable energy, and at the same time, it is energy efficient to sell to neighboring consumers when the quantity of production remains according to the production and consumption patterns and purchase in case of shortage, and guarantee profits to the public. It is possible to propose an energy trading platform that introduces a blockchain that is a transparent, decentralized, and secure transaction log recording method that can fully and continuously track even small and very small energy transactions.

[Figure 1] Typical hyperledger network structure
[Figure 2] World state
[Figure 3] Energy transaction flow chart
[Figure 4] MSP and channel
[Figure 5] Chain code execution example
[Figure 6] Example invoke function
[Figure 7] Example query function
[Fig 8] Seller Information
[Fig 9] Buyer Information
[Figure 10] Algorithm example code
11 is a flowchart of the algorithm from the seller's point of view.
[Figure 12] Simple block structure

Ⅰ. Introduction

In addition to the reduction of greenhouse gas emissions in accordance with the recent agreement on the new climate system, the government is implementing a de-nuclear power policy, so the development of a new and renewable energy business is essential, and an individual is a prosumer who produces and consumes electricity by itself, such as solar light. Is increasing. However, the power generation and consumption patterns are often different, resulting in storage problems, and centralized transactions and power generation centering on KEPCO are also not good in terms of energy efficiency, such as energy loss in power transmission.

In order to efficiently operate renewable energy, a distributed power source is introduced, and at the same time, it is energy efficient to sell to neighboring consumers when the quantity of production remains according to the production and consumption patterns and purchase in the case of shortage. We propose an energy trading platform that introduces a blockchain that is a transparent, distributed, and secure transaction log recording method that can fully and continuously track energy transactions.

Analyze energy production and consumption patterns, register power generation, transmission and reception and transaction devices including generators and transmission/reception data, receive data from the devices, and process it using AWS Blockchain Template for Hyperledger Fabric Magic supported by AWS We propose fast and efficient decentralized P2P transactions.

Hyperledger provides a distributed software architecture that records transparent, decentralized, and secure transaction logs that enable complete and continuous tracking of very small energy transactions, making it much more efficient for energy markets with smaller energy transactions than traditional centralized and large-scale methods. It is expected to respond appropriately to the platform.

Ⅱ. Hyperledger Fabric

In general, Bitcoin, which is the most widely known application, and Ethereum, which is an alternative to blockchain, is a public and permissionless blockchain technology that makes it difficult to request the identity of the participants. In the case of KYC (Know-Your-Customer) or AML (Anti-Money Laundering), it is difficult to comply.

Hyperledger Fabric improves this and is designed for the enterprise from the ground up, making it private and permissive, allowing participants to be authenticated, identifiable, network manageable, high transaction throughput, low transaction latency, low transaction and transaction related data. Confidentiality is maintained. In addition, it is based on a modular architecture that provides a high level of confidentiality, resilience, flexibility, and scalability. It registers users and each node through MSP (Membership Service Provider) to manage identities. It can be used to store in various forms, and the consensus mechanism is modularized to support various algorithms. A unique implementation of Distributed Ledger Technology (DLT) that provides enterprise-class network security, scalability, confidentiality, and performance in a modular blockchain architecture as a platform for distributed ledger solutions. Identity management, privacy and confidentiality, and efficient processing , Chaincode function, modular design support.

Ⅲ. Hyperledger Architecture

Hyperledger's structure allows users to access channels as peers through applications, and conduct transactions on channels with other peers through designated chaincodes, and each channel has its own policy. Transactions made between each peer are ordered according to the network policy in the ordering service, and blocks are created and distributed to all peers. In MSP, it plays the role of CA for all nodes, channels, networks, and each transaction, including administrators. Figure 1 shows a typical hyper-leisure network structure.

Ⅳ. Terms used in Hyper Leisure

The terms used in hyper leisure are as follows [Table 1].

Peer Maintain Ledger, execute Chaincode, and manage digital ledger, transactions, and smart contract. It acts to commit the transaction and plays the role of endorsing according to the policy.
Maintain a blockchain consisting of a state store that stores transaction information in the form of a block in the ledger (persist) and stores state information according to the result of the transaction execution. Ledger This is a concept that consists of sequential and non-tamperable data in the form of a chain, and is an encrypted blockchain including transactions and world state. Changed world state with chaincode. World state It can be said to be a key-value-based database for storing state and data when the chain code is called by a transaction with data of the ledger at a specific point in time. Currently, it supports LevelDB and CouchDB. (See [Figure 2]) Transaction log It maintains a history of updating the world state. Chaincode In Hyperledger, smart contracts are called chain codes, and logic codes that implement various transaction types are distributed and executed on the blockchain. Each node (Peer or Orderer, etc.) is the subject of execution, and when the transaction is executed and validated, it is added to the shared ledger and access and modification of key-value pairs in the world state. It performs functions such as deployment, invoke, and query. (More details in Chapter 6 Chaincode) Endorsing It executes the corresponding chaincode according to the client's warranty request and guarantees the result. The guarantee node and the guarantee method are determined by the guarantee policy associated with the chaincode, and the guarantee policy is written together with the chaincode and placed together when the chaincode is placed in a block. Membership Service Provider (MSP) It registers and manages the user's ID and verifies the identity of all nodes (administrators, general peers, etc.) accessing the hyperledger fabric and issues network access credentials (=certificates). Public key certificates and private keys can be issued as credentials through a public key-based certification authority (CA) to ensure auditability.
It derives all other certificates and verifies that it is a member of the organization (Root CA), acts as a key store for Org's constituent units, administrators, node IDs, and private keys, and provides long-term E-Cert (Enrollment Certificate) In the short term, each transaction manages T-Cert (Transaction Certificate) and TLS (including transport layer security and SLS) at the communication channel level. Orderer (Ordering service node) It serves to order the proposed transactions from clients according to the consensus algorithm and deliver them to the peer node. It orders the transaction messages and delivers them in block form to all peers connected to the channel. It ensures that transaction messages delivered to each peer are delivered safely in the same order. Org(Organization) (Logical) organizational unit that manages peers Channel A private blockchain virtual network that maintains data isolation and confidentiality to share ledgers between peers and applications, with one ledger per channel, shared by all peers on that channel, and trading parties must be properly authenticated to the channel to interact .

Ⅴ. Transaction Flow

In Hyperledger, the order of transactions proceeds as follows. First, when a client initiates a transaction, it creates a transaction proposal that can invoke a chaincode function to read and write data to the ledger, and the SDK packages the transaction proposal and uses the user's cryptographic credentials to make it unique to the transaction proposal. Generate a signature. After that, the assurance peer checks the configuration, validity, policy, etc. along with the signature and executes the chain code against the current state DB to generate and execute the response transaction (the ledger is not updated at this point). The application program (SDK) verifies that the peer's signature and conditions are met, collects the transaction containing the guarantees received from the peers, sends it to the order system, and broadcasts the transaction message to the order service. The order service does not check the transaction details, it simply places the messages received from all channels in order according to the policy and creates blocks per channel. The transaction block is delivered to all peers, checks the approval policy and validity, checks whether the status of the ledger is changed by the transaction, and updates the ledger if it is changed. Each peer adds a block to the channel chain and commits a valid transaction to the current state DB.

[Figure 3] is a schematic diagram including the operation within the peer. 1. When the user connects to the peer through an application program 2. When the transaction request chain code including the invoke statement is sent to the peer 3. The peer sends the chain code Call and read the current status from the 4 chain code as a query and respond to the request. 5. The peer responds to the user's request 6. The application sends the received guarantee and transaction to the orderer 7. The orderer orders the received transaction and delivers it to each peer in block form 8. The peer receives the received content Fig. 4 shows the sequence of updating the ledger through the concept of the MSP and the channel, and the user receives the transaction participant certificate from the MSP and subscribes to the blockchain virtual network channel. If you decide to sell or purchase and enter values accordingly, each transaction is requested and replied to according to the transaction flow. When all transactions are completed, the ordering service sends a transaction to all peers in blocks, and each peer then updates the ledger.

Ⅵ. Chain Code

Chaincode is supported to be written in high-level programming languages Go, Node.js, and Java, and serves as deployment, invoke, and query.

Distribution is the role of placing chaincode in the peer's file system with install(), instantiate(), etc. and starting and initializing the chaincode application on a specific channel. After instantiation, the peer with the chaincode installed can accept the call and its contents are recorded in the block.

The call is the contents such as calling the chaincode function with invoke(), the Client requesting the Peer, or the Peer responding to the Client, etc. and recorded in the block.

Query is read from KVS through chaincode with query(), etc. and is not recorded in the block.

The execution example of the chaincode is the code that installs the chaincode from the first line of [Figure 5] and calls instantiation, version update, upgrade, data inquiry, transaction, and [Figure 6] is an example of the invoke function structure and [Figure 7] is an example of the query function.

Ⅶ. Energy trading system

The transaction system is a process of querying and updating the assets of the ledger, and when the application calls the smart contract (=chain code) through the API through interworking between the application and the network, it consists of a chain code container of the form shown in [Table 2] and operates. .

name fabcar version 1.0 Running peer dev-peer0.org1.example.com

After selecting whether to buy or sell, the user immediately registers the selling price (kWh/won), the minimum selling price (kWh/won), the sales volume (kWh), and the auction time (hour) if it is sold. Enter the purchase amount (kWh). If the seller's (immediate selling price) is less than (purchase price), the transaction is made immediately, and if it is less than (minimum selling price), the transaction is not made. If the (purchase price) registered by the buyer is the price between (immediate selling price) and (minimum selling price), the transaction is made with the (purchasing price) of the buyer who presented the highest price during the registered auction time. If (Sales Volume) is greater than (Purchase Amount), after the transaction (Purchase Amount), the sales code works again as (Sales Volume-Purchase Amount). If (Purchase Amount) is greater than (Sales Amount), the purchase code will work again after (Purchase Amount) after trading for (Sales Volume). If the minimum selling price is not entered, a reconnaissance transaction is made immediately at the selling price and the auction system does not work.

The following [FIG. 8], [FIG. 9], and [FIG. 10] are examples of codes and methods of constructing seller information and buyer information, and examples of algorithms of a transaction system including auction.

11 is a flowchart of the algorithm from the seller's point of view.

Ⅷ. Block

The block contains the number, previous hash, block header and version of the data hash, block creation time (Timestamp), channel ID, TXID (Transaction ID), and chaincode path, chaincode name, chaincode version, creator ID, certificate, Chain code type, 1~n guarantee Peer's guarantee and certificate, public key, hash value of the previous block (512 bits), metadata of the consensus process (selectable), and current state data of KVS (Key-Value Store) It consists of a hash value and a hash value of the following transactions.

Claims (1)

P2P energy trading platform using hyper leisure.

Images