WO2020042129A1

WO2020042129A1 - Systems and methods for blockchain-based energy grid transaction

Info

Publication number: WO2020042129A1
Application number: PCT/CN2018/103390
Authority: WO
Inventors: Jianjun Zhang; Kun Xu; Jijing ZHANG
Original assignee: Powerchaintech Beijing Company
Priority date: 2018-08-31
Filing date: 2018-08-31
Publication date: 2020-03-05

Abstract

A system and a method for energy grid transaction is provided. The system may include a plurality of nodes forming a blockchain network. The plurality of nodes may communicate with each other. The system may further include a user terminal configured to communicate with the blockchain network. The plurality of nodes may include at least one first node. Each of the at least one first node may receive a transaction proposal for energy from the user terminal, generate an endorsement result, and transmit the endorsement result to the user terminal. The user terminal may generate a transaction based on the endorsement result, and transmit the transaction to at least one second node of the plurality of nodes. The at least one second node may order the transaction and generate a block encoding the transaction.

Description

SYSTEMS AND METHODS FOR BLOCKCHAIN-BASED ENERGY GRID TRANSACTION

TECHNICAL FIELD

The present disclosure generally relates to systems and methods for energy grid transaction, and in particular, to systems and methods for energy grid transaction via a blockchain-based platform.

BACKGROUND

Energy supply reliability and sufficiency are fundamentally important for the development of the society. Conventionally, the distribution of energy is controlled by a central system (e.g., State Grid) . For example, conventional power stations, such as a coal-fired plant, a gas plant, a nuclear power plant, and a hydroelectric dam, are centralized and often make electric energy to be transmitted over a long distances, which may cause a waste of resources. Recently, an energy grid (e.g., a microgrid) , which is a distributed group of a plurality of grid elements (such as an energy supplier, an energy consumer, and/or an energy storage) , has emerged, providing a more effective way of energy distribution and management. In the energy grid, energy may be exchanged and/or traded among different grid elements. A blockchain is a technique that maintains a continuously growing list of transaction records. The growing list of transaction records may be recorded in a distributed ledger. The blockchain may guarantee that the transaction records can be stored in a verifiable and permanent way, and not be modified retroactively. Therefore, it is desirable to provide effective systems and methods for energy transaction in an energy grid based on a blockchain platform.

SUMMARY

According to an aspect of the present disclosure, a system for energy grid transaction may be provided. The system may include a plurality of nodes. The plurality of nodes may form a blockchain network. Each of the plurality of nodes may be configured to communicate with each of other nodes of the plurality of nodes. The system may further include a user terminal configured to communicate with the blockchain network, the user terminal being associated with a grid element registered in an energy grid. The plurality of nodes may include at least one first node. Each of the at least one first node may be configured to receive a transaction proposal for energy from the user terminal, generate an endorsement result by endorsing the transaction proposal according to a smart contract, and transmit the endorsement result to the user terminal. The user terminal may be configured to generate a transaction based on the endorsement result received from each of the at least one first node, and transmit the transaction to at least one second node of the plurality of nodes. The at least one second node may be configured to order the transaction and generate a block encoding the transaction.

In some embodiments, the at least one second node may be further configured to transmit the block to at least one third node of the plurality of nodes. Each of the at least one third node may store a distributed ledger and be configured to validate the transaction to generate a validation result, and write the transaction into the distributed leger in response to the validation result that the transaction is valid.

In some embodiments, each of the at least one third node may be further configured to transmit a notification regarding the validation result to the user terminal.

In some embodiments, the transaction proposal may include at least one of an ID of a user of the user terminal, a digital signature of the user, a time stamp, an ID of the smart contract corresponding to the transaction proposal, a type of the energy to be traded, an amount of the energy, a transaction method, or a transaction price of the energy.

In some embodiments, the price of the energy may be represented by a number of tokens, each token representing a value.

In some embodiments, the smart contract may be stored in each of the at least one first node.

In some embodiments, the smart contract may be based at least in part on data related to the smart contract inputted by a user via the user terminal, or the smart contract may be selected from a plurality of predefined smart contracts stored in each of the at least one first node.

In some embodiments, at least one node of the plurality of nodes may be configured to obtain first historical energy consumption information related to the grid element. The at least one node may be configured to predict an energy demand of the grid element at a first predetermined time based on the first historical energy consumption information, and transmit the predicted energy demand to the user terminal for display.

In some embodiments, the predicting the energy demand of the grid element at the first predetermined time may be performed based on at least one of a Bayesian ridge regression algorithm, a linear regression algorithm, an elastic mesh regression algorithm, a support vector regression algorithm, or a gradient boost regression tree algorithm.

In some embodiments, at least one node of the plurality of nodes may be configured to obtain second historical energy consumption information related to the grid element, and settle a historical energy consumption of the grid element at a second predetermined time based on the second historical energy consumption information. The at least one node may be further configured to transmit the historical energy consumption to the user terminal for display.

In some embodiments, the energy may be at least one of electric energy, solar energy, wind energy, fuel energy, hydroelectric power, nuclear energy, marine energy, osmotic energy, biomass energy, or geothermal energy.

In some embodiments, each of the at least one third node may be further configured to store state information related to the blockchain network.

According to another aspect of the present disclosure, a method is provided. The method may be implemented on a system including a plurality of nodes and a user terminal. The plurality of nodes may form a blockchain network. Each of the plurality of nodes may be configured to communicate with each of other nodes of the plurality of nodes. The user terminal may be configured to communicate with the blockchain network and associated with a grid element registered in an energy grid. Each of at least one first node of the plurality of nodes may receive a transaction proposal for energy from the user terminal, generate an endorsement result by endorsing the transaction proposal according to a smart contract, and transmit the endorsement result to the user terminal. The user terminal may generate a transaction based on the endorsement result received from each of the at least one first node, and transmit the transaction to at least one second node of the plurality of nodes. The at least one second node may order the transaction and generate a block encoding the transaction.

Additional features will be set forth in part in the description which follows, and in part will become apparent to those skilled in the art upon examination of the following and the accompanying drawings or may be learned by production or operation of the examples. The features of the present disclosure may be realized and attained by practice or use of various aspects of the methodologies, instrumentalities, and combinations set forth in the detailed examples discussed below.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is further described in terms of exemplary embodiments. These exemplary embodiments are described in detail with reference to the drawings. These embodiments are non-limiting exemplary embodiments, in which like reference numerals represent similar structures throughout the several views of the drawings, and wherein:

FIG. 1 is a schematic diagram illustrating an exemplary energy grid transaction system according to some embodiments of the present disclosure;

FIG. 2 is a schematic diagram illustrating an exemplary blockchain network according to some embodiments of the present disclosure;

FIG. 3 is a flowchart illustrating an exemplary process of an energy transaction based on a blockchain network according to some embodiments of the present disclosure;

FIG. 4 is a schematic diagram illustrating an exemplary process of an energy transaction according to some embodiments of the present disclosure;

FIG. 5 is a schematic diagram illustrating an exemplary distributed ledger according to some embodiments of the present disclosure;

FIG. 6 is a schematic diagram illustrating an exemplary smart contract according to some embodiments of the present disclosure;

FIG. 7 is a schematic diagram illustrating exemplary hardware and/or software components of a computing device according to some embodiments of the present disclosure;

FIG. 8 is a schematic diagram illustrating exemplary hardware and/or software components of a mobile device according to some embodiments of the present disclosure;

FIG. 9A and FIG. 9B are schematic diagrams illustrating an exemplary predicted energy demand of a grid element according to some embodiments of the present disclosure; and

FIG. 10A and FIG. 10B are schematic diagrams illustrating an exemplary settlement result of a historical energy consumption of a grid element according to some embodiments of the present disclosure.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled in the art to make and use the present disclosure and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present disclosure. Thus, the present disclosure is not limited to some embodiments shown but is to be accorded the widest scope consistent with the claims.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used herein, the singular forms “a, ” “an, ” and “the” may be intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprise, ” “comprises, ” and/or “comprising, ” “include, ” “includes, ” and/or “including, ” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

These and other features, and characteristics of the present disclosure, as well as the methods of operation and functions of the related elements of structure and the combination of parts and economies of manufacture, may become more apparent upon consideration of the following description with reference to the accompanying drawings, all of which form a part of this disclosure. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended to limit the scope of the present disclosure. It is understood that the drawings are not to scale.

The flowcharts used in the present disclosure illustrate operations that systems implement according to some embodiments of the present disclosure. It is to be expressly understood, the operations of the flowchart may be implemented not in order. Conversely, the operations may be implemented in inverted order, or simultaneously. Moreover, one or more other operations may be added to the flowcharts. One or more operations may be removed from the flowcharts.

FIG. 1 is a schematic diagram illustrating an exemplary energy grid transaction system 100 according to some embodiments of the present disclosure. The energy grid transaction system 100 (also referred to as a transaction system 100 for brevity hereinafter) may function as an energy-trading platform that enables a peer-to-peer transaction within an energy grid based on a blockchain network 110. In some embodiments, the transaction system 100 may also function as an intelligent communication and management platform that can provide services, such as contract management, transaction settlement, energy demand forecasting, energy efficiency analyzing, energy distribution, user management, information publishing, transaction monitoring, marketing analysis, or the like, or any combination thereof.

The energy grid may be a distributed energy network including one or more grid elements. As used herein, a grid element may refer to an entity that can participate in an energy exchange and/or transaction. The energy exchanged and/or traded within the energy grid may include any type of energy, such as electric energy, solar energy, wind energy, fuel energy (e.g., gas, petroleum, or coal) , hydroelectric power, nuclear energy, marine energy, osmotic energy, biomass energy, geothermal energy or the like, or any combination thereof.

Exemplary grid elements of the energy grid may include an energy supplier, an energy consumer, an energy storage, an energy broker, or the like, or any combination thereof. The energy supplier may include any entity that is capable of suppling energy. Exemplary energy suppliers may include a wind power plant, a photovoltaic (PV) power device, a PV power plant, a nuclear power plant, a hydroelectric power plant, a thermal power plant, a marine power plant, an osmotic power plant, a biomass energy plant, or the like, or any combination thereof. The energy consumer may include any entity that can consume energy. Exemplary energy consumers may include a building (e.g., a residential building, a commercial building, an industrial building) , an institution, an electric equipment (e.g., a laptop, a smartphone, an electric car) , or the like, or any combination thereof. The energy storage may include any entity that is capable of storing energy. Exemplary energy storage may include a pumped storage, a compressed air energy storage, a superconducting magnetic energy storage, a battery/rechargeable battery, a thermal energy storage, a hydrogen storage, a flywheel energy storage, or the like, or any combination thereof. Merely by way of example, as shown in FIG. 1, the grid elements of the energy grid may include a building 120, a power convert system 130, a thermal power plant 140, a PV power device 150, and an electric car 160.

In some embodiments, a grid element may be associated with a plurality of types of devices, such as an energy-supplying device, an energy-consuming device, and an energy storage device. In such cases, a grid element may both be an energy supplier, an energy consumer, and/or an energy storage. For example, the building 120 including a plurality of electric equipment and a PV power device can not only consume power but also generate power. As another example, the PV power device 150 may supply energy and include a solar pond used to store solar energy. In some embodiments, a grid element may both be an energy supplier and an energy prosumer. In some embodiments, a grid element together with the associated device (s) may operate as an integrated grid element. Additionally or alternatively, a device associated with the grid element may operate as an independent grid element that participate in an energy exchange and/or transaction in the transaction system 100. Merely by way of example, the building 120 and the devices therein may be regarded as the grid element of building 120. Additionally or alternatively, the PV power device of the building 120 may operate as an independent grid element.

In some embodiments, two or more grid elements of the energy grid may be connected to each other to exchange energy. Merely by way of example, the power convert system 130, the thermal power plant 140, and/or the PV power device 150 may supply electricity to the building 120 and the electric car 160. As another example, the power convert system 130 may obtain energy from one or more other grid elements and store the energy. As another example, the building 120, the thermal power plant 140, and the PV power device 150 may obtain energy from or provide energy to the power convert system 130.

The blockchain network 110 may be configured to process and/or store an energy transaction occurred in the transaction system 100. As used herein, an energy transaction may refer to any successful or failed energy transaction. The energy transaction may be started by any grid element in the energy grid. For example, the energy transaction may be an energy buying transaction started by an energy consumer or an energy selling transaction started by an energy supplier.

The blockchain network 110 may utilize a decentralized, distributed, and public digital ledger to maintain a continuously growing list of transaction records. The blockchain network 110 may guarantee that the transaction records can be stored in a verifiable and permanent way and not be modified retroactively. The blockchain network 110 may be of any type of blockchain network, such as a public blockchain network, a private blockchain network, a semi-private blockchain network, a consortium blockchain network, or the like, or any combination thereof.

In some embodiments, the blockchain network 110 may be a consortium blockchain network in which a consensus process is controlled by a pre-selected set of nodes. The right to read the blockchain may be public or restricted to the pre-selected set of nodes. In some embodiments, the blockchain network 110 may be built based on a Hyperledger fabric blockchain. The blockchain network 110 may include a plurality of nodes, which may be assigned with different functions such as data storing, transaction endorsement, smart contract execution, transaction validation, data analyzing, or the like, or any combination thereof.

In operation, the blockchain network 110 may allow a user associated with a grid element (e.g., an energy supplier and/or an energy consumer) to sell energy to and/or buy energy from another grid element. For example, an energy supplier may sell energy to its neighboring grid element (e.g., a grid element within a certain distance away from the energy supplier) . The user of the grid element may participate in the blockchain network 110 by starting a transaction via a user terminal (not shown in FIG. 1) . In response to the transaction, the blockchain network 110 may validate the transaction according to a smart contract, and store the transaction into a block that is sealed with a lock (also referred to as a “hash” ) if the transaction is valid. Details regarding the terminal device and the energy transaction process may be found elsewhere in the present disclosure (e.g., FIGs. 2 to 4 and the relevant descriptions thereof) .

It should be noted that the above description of the transaction system 100 is merely provided for the purposes of illustration, and not intended to limit the scope of the present disclosure. For persons having ordinary skills in the art, multiple variations and modifications may be made under the teachings of the present disclosure. However, those variations and modifications do not depart from the scope of the present disclosure. In some embodiments, one or more optionally components may be added in the transaction system 100 or one or more components of the transaction system 100 mentioned above may be omitted. For example, the electric car 160 may be omitted. In some embodiments, the energy grid may exchange energy with an external energy source (e.g., a state grid, another energy grid) .

FIG. 2 is a schematic diagram illustrating an exemplary blockchain network 110 according to some embodiments of the present disclosure. As described in connection with FIG. 1, the blockchain network 110 may be configured to process and record an energy transaction occurred in the transaction system 100.

As shown in FIG. 2, the blockchain network 110 may be a decentralized network of a plurality of nodes 210. The nodes 210 may be connected to each other via a network 220 instead of connected to a central server. As used herein, a node 210 may refer to a computing unit is capable of executing one or more functions of the node 210 disclosed in the present disclosure. The node 210 may be implemented on any type of computing device. For example, a node 210 may be implemented on a computing device, such as a personal computer, a tablet computer, a laptop computer, a mobile device, or the like, or a portion of the computing device. As another example, a node 210 may be implemented on a computing system including a plurality of computing devices. In some embodiments, a node 210 may be implemented on one or more components of a computing device 700 as shown in FIG. 7. In some embodiments, a node 210 may be implemented on as a Docker. . In some embodiments, a node 210 may be implemented on a cloud platform. Merely by way of example, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a community cloud, a distributed cloud, an inter-cloud, a multi-cloud, or the like, or any combination thereof.

In some embodiments, the plurality of nodes 210 may have the same or different functions in the blockchain network 110. Merely by way of example, the nodes 210 may include a peer, an orderer, and/or a certificate authority. The peer may refer to a node 210 that maintain a distributed ledger and/or run a smart contract (also be referred to as chaincode) in order to perform read/write operations to the distributed ledger. The distributed ledger may be a consensus of shared digital data geographically spread across one or more nodes 210. The distributed ledger may be used store to a blockchain and optionally other information related to the transaction system 100 (e.g., world state information) . The smart contract may refer to a self-executing contract encoding rules for energy transaction.

The peer may include an endorser and a committer. The endorser may refer to a node 210 that is configured to endorse a transaction proposal received from the user terminal 240 to generate an endorsement result. The committer may refer to a node 210 that is configured to validate a transaction and/or an endorsement result. The orderer may refer to a node 210 that is configured to order one or more transactions into a block. The certificate authority may refer to a node 210 that is configured to manage membership in the transaction system 100. In some embodiments, a node 210 may function as a single type of node 210. Alternatively, a node 210 may function as a plurality of types of nodes. Merely by way of example, a node 210 may function as both an endorser and a committer.

In some embodiments, one or more nodes 210 of the blockchain network 110 may be configured to analyze and/or manage information related to the transaction system 100 to provide a plurality of services, such as contract management, transaction settlement, energy demand forecasting, energy efficiency analyzing, energy distribution, user management, information publishing, transaction monitoring, marketing analysis, or the like, or any combination thereof. For example, the node 210 may provide a user management service, such as user registration, user authentication, user information update, user account monitoring, user account suspension, or the like, or any combination thereof. As another example, the node 210 may provide a contract management service, such as contract creation, contract execution, contract inquiry, contract confirmation, contract cancellation, or the like, or any combination thereof. In some embodiments, a user associated with a grid element may send a request for a certain service to a node 210 via the user terminal 240. In response to the request, the node 210 may execute the request and transmit the execution result to the user terminal 240, so as to provide the requested service to the user.

In some embodiments, a node 210 of the blockchain network 110 may be owned and maintained by an entity (e.g., an organization, a person) that maintains the transaction system 100. Alternatively, the node 210 may be owned and maintained by a user associated with a grid element of the energy grid.

The network 220 may facilitate exchange of information and/or data. For example, the plurality of nodes 210 of the blockchain network 110 may be connected to and/or communicate with each other via the network 220. As another example, one or more nodes 210 of the blockchain network 110 may be connected to and/or communicate with the user terminal 240 via the network 220. In some embodiments, the network 220 may be any type of wired or wireless network, or combination thereof. Merely by way of example, the network 220 may include a cable network, a wireline network, an optical fiber network, a tele communications network, an intranet, an Internet, a local area network (LAN) , a wide area network (WAN) , a wireless local area network (WLAN) , a metropolitan area network (MAN) , a public telephone switched network (PSTN) , a Bluetooth network, a ZigBee network, a near field communication (NFC) network, or the like, or a combination thereof. In some embodiments, the network 220 may include one or more network access points. For example, the network 220 may include wired or wireless network access points such as base stations and/or internet exchange points 220-1, 220-2, …, through which one or more components of the transaction system 100 may be connected to the network 220 to exchange data and/or information.

As shown in FIG. 2, the blockchain network 110 may be connected to and/or communicated with a storage device 230 and/or a user terminal 240. The storage device 230 may be configured to store data and/or instructions. In some embodiments, the storage device 230 may store data obtained from one or more node (s) 210 and/or the user terminal 240. For example, the storage device 230 may store information related to the transaction system 100, such as user information, raw transaction information, processed transaction data received from the blockchain network 110, policy information, news information, or the like, or any combination thereof. As another example, the storage device 230 may store a block index and a historical index of a key. In some embodiments, the storage device 230 may store data and/or instructions that the blockchain network 110 may execute or use to perform exemplary methods described in the present disclosure.

In some embodiments, the storage device 230 may include a mass storage, removable storage, a volatile read-and-write memory, a read-only memory (ROM) , or the like, or a combination thereof. Exemplary mass storage may include a magnetic disk, an optical disk, a solid-state drive, etc. Exemplary removable storage may include a flash drive, a floppy disk, an optical disk, a memory card, a zip disk, a magnetic tape, etc. Exemplary volatile read-and-write memory may include a random access memory (RAM) . Exemplary RAM may include a dynamic RAM (DRAM) , a double date rate synchronous dynamic RAM (DDR SDRAM) , a static RAM (SRAM) , a thyristor RAM (T-RAM) , and a zero-capacitor RAM (Z-RAM) , etc. Exemplary ROM may include a mask ROM (MROM) , a programmable ROM (PROM) , an erasable programmable ROM (EPROM) , an electrically erasable programmable ROM (EEPROM) , a compact disk ROM (CD-ROM) , and a digital versatile disk ROM, etc. In some embodiments, the storage device 230 may be implemented on a cloud platform. Merely by way of example, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a community cloud, a distributed cloud, an inter-cloud, a multi-cloud, or the like, or a combination thereof.

In some embodiments, the storage device 230 may be connected to the network 220 to communicate with the user terminal 240 and/or one or more nodes 210 of the blockchain network 110. Additionally or alternatively, the storage device 230 may be directly connected to or communicate with the user terminal 240 and/or one or more nodes 210 of the blockchain network 110. In some embodiments, the storage device 230 may be part of a node 210.

In some embodiments, one or more components of the transaction system 100 (e.g., the nodes 210, and the user terminal 240) may access the storage device 230. In some embodiments, one or more components of the transaction system 100 may read and/or write information relating to one or more transactions when one or more conditions are met. For example, a node 210 may read and/or modify information relating to one or more transactions stored in the storage device 230. As another example, the user terminal 240 may access information stored in the storage device 230 but have no permission to modify the information stored in the storage device 230.

The user terminal 240 may be associated with a grid element of the energy grid, and configured to enable a user interaction between a user associated with the grid element and the blockchain network 110. For example, the user terminal 240 may be associated with the thermal power plant 140. An administrator or an employee of the thermal power plant 140 may transmit a transaction proposal to the blockchain network 110 via the user terminal 240 to sell surplus energy. As another example, the user terminal 240 may be associated with the building 120. A resident of the building 120 may transmit a transaction proposal to the blockchain network 110 via the user terminal 240 to buy energy. Additionally or alternatively, the resident may submit a request to the blockchain network 110 via the user terminal 240 to predict his/her energy demand in the next month.

In some embodiments, the user terminal 240 may include a software development kit (SDK) . The SDK may provide an application programming interface (API) to connect to the blockchain network 110, and enable the user terminal 240 to interact with the blockchain network 110. For example, the SDK may package a transaction proposal inputted by a user into a properly architected format and/or produce a unique signature (e.g., a digital signature) for this transaction proposal. In some embodiments, the user terminal 240 may be installed with a client application. The client application may be designed to enable a user of the user terminal 240 to transact and/or manage energy based on the blockchain network 110. For example, the user may transmit a transaction proposal for energy to the blockchain network 110 via client application. As another example, the user may view information (e.g., a predicted energy demand, a settlement result regarding historical energy consumption, an analyzing result of energy efficiency, a warning) on the client application. The client application may be a mobile application, a web application, a cloud application, a website, or any other software for energy transaction.

In some embodiments, the user terminal 240 may be connected to or communicated with one or more components of the blockchain network 110 (e.g., one or more nodes 210) via the network 220. Additionally or alternatively, the user terminal 240 may be connected to one or more components of the blockchain network 110 directly. In some embodiments, different users of the user terminal 240 may have different user permissions depending on the type of the users (e.g., a registered user, a VIP, a visitor) . For example, a registered user may have a permission to transact energy on the blockchain network 110 and read transaction information related to the blockchain network 110. A visitor may only have a permission to read transaction information related to the blockchain network 110.

In some embodiments, the user terminal 240 may be configured to encrypt and decrypt information. For example, the user terminal 240 may hold a private key and a public key. The public key may be public and available for any component in the transaction system 100. The private key may be hold privately by a certain component in the transaction system 100. When transmitting a message to another component of the transaction system 100, the user terminal 240 may encrypt the message using its private key and digitally signs the message. When receiving a message from another component of the transaction system 100, the user terminal 240 may decrypt the message using a public key of the another component and/or validate the message.

In some embodiments, the user terminal 240 may include a mobile device 240-1, a tablet computer 240-2, a laptop computer 240-3, a built-in device 240-4, or the like, or a combination thereof. In some embodiments, the mobile device 240-1 may include a smart home device, a wearable device, a smart mobile device, a virtual reality device, an augmented reality device, or the like, or a combination thereof. In some embodiments, the smart home device may include a smart lighting device, a control device of an intelligent electrical apparatus, a smart monitoring device, a smart television, a smart video camera, an interphone, or the like, or a combination thereof. In some embodiments, the wearable device may include a smart bracelet, a smart footgear, a smart glass, a smart helmet, a smartwatch, a smart clothing, a smart backpack, a smart accessory, or the like, or a combination thereof. In some embodiments, the smart mobile device may include a smartphone, a personal digital assistant (PDA) , a gaming device, a navigation device, a point of sale (POS) device, or the like, or a combination thereof. In some embodiments, the virtual reality device and/or the augmented reality device may include a virtual reality helmet, a virtual reality glass, a virtual reality patch, an augmented reality helmet, an augmented reality glass, an augmented reality patch, or the like, or a combination thereof. For example, the virtual reality device and/or the augmented reality device may include a Google Glass ^TM, a RiftCon ^TM, a Fragments ^TM, a Gear VR ^TM, etc.

It should be noted that the example illustrated in FIG. 2 and the description thereof are merely provided for the purposes of illustration, and not intended to limit the scope of the present disclosure. For persons having ordinary skills in the art, multiple variations and modifications may be made under the teachings of the present disclosure. However, those variations and modifications do not depart from the scope of the present disclosure. In some embodiments, the blockchain network 110 may include any number of component nodes 210. A node 210 may be assigned with any function. In some embodiments, the storage device 230 may be omitted.

FIG. 3 is a flowchart illustrating an exemplary process of an energy transaction based on a blockchain network according to some embodiments of the present disclosure. The process 300 may be executed by the transaction system 100. For example, the process 300 may be implemented as a set of instructions (e.g., an application) stored in a storage device (e.g., a storage device of a node 210, the storage device 230) . One or more components of the transaction system 100 may execute the set of instructions, and when executing the instructions, the one or more components of the transaction system 100 may be configured to perform the process 300. The operations of the illustrated process presented below are intended to be illustrative. In some embodiments, the process 300 may be accomplished with one or more additional operations not described and/or without one or more of the operations discussed. Additionally, the order in which the operations of the process as illustrated in FIG. 3 and described below is not intended to be limiting. In some embodiments, the process 300 may also be referred to as a consensus process.

As described in connection with FIG. 2, the blockchain network 110 may include a plurality of nodes 210. Each of the plurality of nodes 210 may be configured to communicate with each of other nodes of blockchain network 110. A user terminal 240 associated with a grid element of an energy grid may be connected to and/or communicated with the blockchain network 110. For example, the user terminal 240 may be connected to and/or communicated with one or more of the plurality of nodes 210.

In 302, each of at least one first node of the plurality of nodes 210 may receive a transaction proposal for energy from the user terminal 240. Each first node may generate an endorsement result by endorsing the transaction proposal according to a smart contract, and transmit the endorsement result to the user terminal. As used herein, a first node that receive and endorse the transaction proposal may also be referred to as an endorser.

In some embodiments, the transaction proposal may be sent by a user associated with the grid element via the user terminal 240. The transaction proposal may be a transaction proposal to buy or sell energy in the transaction system 100. For example, the user may send the transaction proposal using a client application installed on the user terminal 240. In some embodiments, the client application may use a SDK (e.g., a Node SDK, a Java SDK, or a Python SDK) and utilize an API to generate the transaction proposal. Optionally, the client application may produce a digital signature using a cryptographic credential of the user. In some embodiments, the transaction proposal may include at least one of an ID of the user of the user terminal 240, a digital signature of the user, a time stamp, an ID of the smart contract corresponding to the transaction proposal, a type of the energy to be traded, an amount of the energy, a transaction method, or a transaction price of the energy, or the like, or any combination thereof.

In response to the received transaction proposal, each first node may endorse the transaction proposal by first verifying the transaction proposal. For example, each first node may verify that the transaction proposal is well formed and/or the transaction proposal has not been submitted already in the past. Additionally or alternatively, each first node may verify that the digital signature of the transaction proposal is valid and the submitter of the transaction proposal is properly authorized to submit the transaction proposal. After verifying the transaction proposal, each first node may independently simulate the execution of the smart contract using a transaction proposal to generate a transaction result. Each first node may transmit the transaction result, along with its digital signature back as an endorsement result to the user terminal 240. None of the first node (s) may update the distributed ledger at this point.

In some embodiments, the first node (s) that receive and endorse the transaction proposal may be any node of the blockchain network 110. In some embodiments, the first node (s) may be selected among the nodes 210 according to an endorsement policy. The endorsement policy may define one or more nodes 210 that need to endorse a specific type of transaction proposal. Additionally or alternatively, the endorsement policy may define a requirement for a valid endorsement of the transaction proposal. For example, the endorsement policy may require that the transaction endorsement by the first node (s) is valid unless the transaction proposal is endorsed by a minimum number or percentage of the first node (s) , or by all of the first node (s) . Merely by way of example, an exemplary endorsement policy may define that first nodes A, B, and C need to endorse a transaction proposal for electricity. Additionally or alternatively, the exemplary endorsement policy may define that the endorsement of the transaction proposal for electricity is valid if at least two of A, B, and C endorse the transaction proposal.

The smart contract may refer to a self-executing contract encoding rules for energy transaction. For example, the smart contract may include terms of agreements regarding an energy transaction between two parties. Each of the first node (s) may store the smart contract. In some embodiments, each first node may endorse the transaction proposal according to a smart contract associated with the transaction proposal. Merely by way of example, the transaction proposal may define an ID of a smart contract to be executed, and the first node (s) may perform the endorsement based on the defined smart contract. As another example, the first node (s) may perform the endorsement based on a smart contract that is signed by a user associated with the user terminal 240 (e.g., a manager of the corresponding grid element) . In some embodiments, the smart contract may be of various types, such as a customized smart contract, a predefined smart contract, an open smart contract, a long-term smart contract, a short-term smart contract. Details regarding the smart contract may be found elsewhere in the present disclosure (e.g., FIG. 6 and the relevant descriptions thereof) .

In 304, the user terminal 240 may generate a transaction based on the received endorsement result (s) and transmit the transaction to at least one second node. The transaction may include the received endorsement result (s) .

In some embodiments, the user terminal 240 may generate the transaction only when or after it receives endorsement result (s) from “enough” first node (s) . As used herein, if the user terminal 240 receives endorsement result (s) from a predetermined number of first nodes, it may determine that it has received endorsement result (s) from “enough” first node (s) . In some embodiments, the predetermined number of first nodes may be defined by a requirement of a valid endorsement in the endorsement policy as described in connection with operation 302. For example, an endorsement policy may define that as long as two of the three nodes E ₀, E ₁, and E ₂ transmit the endorsement results to user terminal 240, the endorsement of the transaction proposal is valid. In such case, the user terminal 240 may generate a transaction once it receives two endorsement results from E ₀, E ₁, and E ₂. In some embodiments, if the user terminal 240 fails to receive “enough” endorsement result (s) , the transaction proposal may be discarded and the user may need to start a new transaction proposal.

In 306, the at least one second node may order the transaction together with one or more other transaction (s) received from other user terminals. The at least one second node may generate a block encoding the transaction received from the user terminal 240 and the other transaction (s) , and transmit the block to at least one third node. As used herein, a second node configured to order transactions may also be referred to as an orderer.

In some embodiments, the transaction may be packaged along with other transactions into a block in any order. The at least one second node may order the transactions according to an ordering mechanism, such as a SOLO ordering mechanism, an Apache Kafka ordering mechanism, a Simplified Byzantine Fault Tolerance (SBFT) ordering mechanism, or the like, or any combination thereof.

In 308, each of the at least one third node may validate the transaction. Each third node may store a distributed ledger. Each third node may write the transaction into the distributed ledger in response to a determination that the transaction is valid. As used herein, a third node configured to validate the transaction may also be referred to as a committer. In some embodiments, the at least one second node may transmit the block to each committer to which the at least one second node is connected to.

Upon receipt of the block, each third node may validate each transaction encoded in the block. For every transaction, each third node may validate that the endorsement policy of the transaction has been fulfilled. For example, each third node may validate that the corresponding transaction proposal of the transaction has been consistently endorsed by the required first node (s) according to the smart contract. Additionally or alternatively, each third node may perform a distributed ledger consistency check to verify that the current state of the distributed ledger is compatible with the state of the distributed ledger when the block was generated. If a third node determines that the endorsement policy of the transaction has been fulfilled and the current state of the distributed ledger is compatible with the state of the distributed ledger when the block was generated, the third node may generate a validation result that the transaction is valid. In response to the validation result that the transaction is valid, the third node may update the distributed ledger by writing the transaction into the distributed ledger. On the other hand, if the third node determines that the endorsement policy of the transaction has not been fulfilled or the current state of the distributed ledger is incompatible with the state of the distributed ledger when the block was generated, the third node may determine that the transaction is invalid. An invalid transaction may not be applied to the distributed ledger, but be retained for audit purpose.

It should be noted that the above description of the process 300 is merely provided for the purposes of illustration, and not intended to limit the scope of the present disclosure. For persons having ordinary skills in the art, multiple variations and modifications may be made under the teachings of the present disclosure. However, those variations and modifications do not depart from the scope of the present disclosure. In some embodiments, any two of a first node, a second node, and a third node described above may be the same node 210 or different nodes 210. For example, a first node configured to endorse the transaction proposal and a third node configured to validate the transaction may be the same node. In some embodiments, different transactions in the transaction system 100 may be processed by different node (s) of the blockchain network 110. For example, different transaction proposals may be endorsed by different first node (s) of the blockchain network 110. As another example, different transactions may be validated by different third nodes of the blockchain network 110.

In some embodiments, the price of energy in the transaction system 100 may be represented by a number of tokens. For example, the price of energy to be traded defined in a transaction proposal may be represented by one or more of tokens. Each token may represent a value. For example, one token may represent a certain amount of legal currency (e.g., US dollar, RMB, franc) . In some embodiments, the transaction system 100 may issue a plurality of tokens in the transaction system 100 to facilitate transactions between different grid elements. The tokens may be transferred between two parties after a transaction is complete. In some embodiments, one or more tokens may be rewarded to a participant of the transaction system 100 who contributes to the transaction system 100. For example, one or more tokens may be rewarded to a participant who share energy related information, introduce a new participant, solve a problem during an energy transaction, or the like, or any combination thereof.

FIG. 4 is a schematic diagram illustrating an exemplary process of an energy transaction based on a blockchain network 400 according to some embodiments of the present disclosure. The blockchain network 400 may be an example of the blockchain network 110 as described elsewhere in this disclosure. As shown in FIG. 4, the blockchain network 400 may include a plurality of peers (i.e., endorsers E ₀ to E ₂ and committers C ₃ and C ₄) and a plurality of orderers O ₀ to O ₄. Each of the peers may be configured to hold a distributed ledger and/or run one or more smart contracts. The distributed ledger may include a plurality of blocks. The orderers O ₀ to O ₄ may provide an ordering service.

In 402, a user may submit a transaction proposal via the user terminal 240 to the blockchain network 400. As described in connection with operation 302, one or more peers that need to endorse the transaction proposal may be defined by an endorsement policy. For example, as shown in FIG. 4, the endorsement policy may define that the peers E ₀, E ₁, and E ₂ are required to be involved in the transaction proposal endorsement. In such case, the transaction proposal is transmitted to each of the E ₀, E ₁, and E ₂, respectively.

In response to the received transaction proposal, each of the endorsers E ₀, E ₁, and E ₂ may execute the transaction proposal according to a smart contract to generate an endorsement result. Each endorser may not update the distributed ledger stored therein, but rather sign the endorsement result and return the endorsement result to the user terminal 240.

In 404, when and/or after receiving signed endorsement result (s) from “enough” peer (s) , the user terminal 240 may generate a transaction including the signed endorsement result (s) , and transmit the transaction to one or more of the orders O ₁-O ₄.

In 406, the orderer (s) that receive the transaction from the user terminal 240 may order the transaction together with other transaction (s) received from other user terminals (not shown in FIG. 4) . The orderer (s) may package the transactions received from the user terminal 240 and the other user terminal (s) into a block, and subsequently distribute the block to each of the peers connected to the orderer (s) . As shown in FIG. 4, in 406, the orderer (s) may distribute a block including the transaction submitted by the user terminal 240 and the other transaction (s) to the peers E ₀, E ₁, E ₂, C ₃, and C ₄ for validation.

In 408, each of the peers that receives the block from the orderer may validate each transaction in the block, including the transaction submitted by the user terminal 240. For the transaction submitted by the user terminal 240, each peer may validate that whether the endorsement result (s) of transaction are correct and whether the transaction is compatible with current state of the distributed ledger. In response to a determination that the endorsement result (s) are correct and the transaction is compatible with the current state of the distributed ledger, each peer may determine that the transaction submitted by the user terminal 240 is valid. Upon the validation result that the transaction is valid, each peer may update its distributed ledger by writing the transaction submitted by the user terminal 240 into the distributed ledger.

In some embodiments, a notification regarding the validation result may be sent to the user terminal 240 when the transaction submitted by the user terminal 240 succeed or fail and/or when the corresponding block is added to the distributed ledger. The notification may be sent out by each peer connected to the user terminal 240. For example, each of the peers E ₀, E ₁, E ₂, C ₃, and C ₄ may send a notification to the user terminal 240 when the transaction submitted by the user terminal 240 is validated.

FIG. 5 is a schematic diagram illustrating an exemplary distributed ledger 500 according to some embodiments of the present disclosure. As shown in FIG. 5, the distributed ledger 500 may include a blockchain 510 and a state database 520 (also referred to as world state) .

The blockchain 510 may include a plurality of blocks (e.g., block 510A, block 510B) . Each block may record a set of transactions and be cryptographically linked to a previous block. In some embodiments, each block may include three segments, i.e., a header, data, and metadata. The header of a block may encode, for example, a unique block number, a hash of a previous block’s header, and/or a hash of the data segment of the current block. The data segment of a block may encode a set of ordered transaction. In some embodiments, the information recorded by blockchain 510 may be immutable. Once a block is added to the chain, the data in the block cannot be altered. In some embodiments, the blockchain 510 may be stored as a file.

The state database 520 may store the current value of a set of key-value pairs that have been added, modified, or deleted by the set of validated transactions in the blockchain 510. The state database 520 may represent the latest values for all keys included in the blockchain 510. The state database 520 may change when the value of a key changes or a new key is added. For example, a key may be “an ownership of a car” , and the value of the key may change when the car is traded from one owner to another. In such case, the state database 520 may change accordingly. In some embodiments, the state database 520 may be a Level database and/or a Couch database.

In some embodiments, one or more nodes 210 of the blockchain network 110 may hold a copy of the distributed ledger 500 as described elsewhere in this disclosure. For example, each peer (e.g., a committer or an endorser) in the blockchain network 110 may hold or maintain its own copy of the distributed ledger 500, which is kept consistent with every other peer’s copy through a consensus process (e.g., the process 300 or 400) .

FIG. 6 is a schematic diagram illustrating an exemplary smart contract 600 according to some embodiments of the present disclosure. As described in connection with FIG. 3, a smart contract may be a self-executing contract encoding rules for energy transaction. For example, the smart contract may include terms of agreements between two parties, e.g., an energy buyer and an energy seller.

As illustrated in FIG. 6, the smart contract 600

may stipulate a first party and a second party that signed the smart contract 600, an amount of energy to be traded between the first party and the second party, the type of energy to be traded between the first party and the second party, a transaction price, an effective date of the smart contract 600, an expiration date of the smart contract 600, a type of the smart contract 600, a status of the smart contract 600, a contraction duration, or the like, or any combination thereof. The first party and the second party may be associated with a grid element registered in an energy gird, respectively. The type of energy to be traded may include electric energy, solar energy, wind energy, fuel energy, hydroelectric power, nuclear energy, marine energy, osmotic energy, biomass energy, geothermal energy, or the like, or any combination thereof. The type of the smart contract 600 may include, for example, a customized smart contract, a predefined smart contract, an open smart contract, a long-term smart contract, a short-term smart contract, or the like, or any combination thereof.

As used herein, the customized smart contract may refer to a smart contract that is based at least in part on data related to the smart contract inputted by a user via a user terminal 240. For example, the first party and/or the second party of the smart contract may input data via the user terminal 240 to add, remove, and/or modify one or more terms of agreements in the smart contract. In some embodiments, the customized smart contract may be written by the first party and/or the second party using a Domain Specific Language (DSL) (e.g., go, node. js) . Alternatively, the first party and/or the second party of the customized smart contract may input one or more terms of agreements in a natural language into the user terminal 240. The a node 210 of the blockchain network 110 and/or the user terminal 240 may then convert the inputted term (s) into the customized smart contract.

The predefined smart contract may be selected from one of a plurality of predefined smart contracts stored in one or more nodes 210 (e.g., one or more endorsers) of the blockchain network 110. The plurality of predefined smart contracts may include one or more predetermined terms of agreements between the first and the second parities. In some embodiments, the predefined smart contracts may be generated using a machine learning algorithm based on sample data. The sample data may include, such as a plurality of customized smart contracts, common knowledge, a national policy and/or regulation regarding energy trading, or the like, or any combination thereof. For example, the predefined smart contracts may be generated based on a plurality of customized smart contracts defined by users of the transaction system 100 using a machine learning algorithm. Exemplary machine learning algorithm may include but not be limited to an artificial neural network algorithm, a deep learning algorithm, a decision tree algorithm, an association rule algorithm, an inductive logic programming algorithm, a support vector machines algorithm, a clustering algorithm, a Bayesian networks algorithm, a reinforcement learning algorithm, a representation learning algorithm, a similarity and metric learning algorithm, a sparse dictionary learning algorithm, a genetic algorithms, a rule-based machine learning algorithm, or the like, or any combination thereof.

The open smart contract may include a contract that is constructed by a single participant of the transaction system 100. The open smart contract may automatically execute itself when another participant of the transaction system 100 meets all the contract terms. Additionally or alternatively, an open smart contract may include a contract the term (s) of which do not describe the entire agreement between the two parties. For example, the open smart contract may be constructed without an end date, and the contract may continue as long as both parties are satisfied with the contract.

The long-term smart contract may refer to a smart contract whose duration is equal to or longer than a first threshold (e.g., a year, half of a year) . The short-term smart contract may refer to a smart contract whose duration is equal to or shorter than a first threshold (e.g., a month) . In some embodiments, the long-term smart contract may be an annual contract. The short-term smart contract may be a monthly contract. In some embodiments, two parties may signed an annual smart contract regarding an amount of energy for transaction in one year. They may also sign a monthly smart contract when one party has an unexpected demand for energy.

In some embodiments, the smart contract 600 may be constructed by the first party and/or the second party on a client application for energy transaction installed in a user terminal 240. For example, the first party may input terms of agreement into the client application installed in his/her user terminal 240 to construct an initial smart contract. After the initial smart contract is confirmed by the second party, it may become a formal smart contract. In some embodiments, the smart contract 600 may be managed by the first party and/or the second party on the client application. For example, the first party and/or the second party may search, view, modify, cancel, download, print, and/or confirm the smart contract 600 on the client application.

It should be noted that the example illustrated in FIG. 6 and the above description thereof are merely provided for the purposes of illustration, and not intended to limit the scope of the present disclosure. For persons having ordinary skills in the art, multiple variations and modifications may be made under the teachings of the present disclosure. However, those variations and modifications do not depart from the scope of the present disclosure. In some embodiments, the smart contract 600 may include one or more additional terms. Additionally or alternatively, one or more terms of the smart contract 600 mentioned above may be omitted. FIG. 7 is a schematic diagram illustrating exemplary hardware and software components of a computing device 700 according to some embodiments of the present disclosure.

The computing device 700 may be used to implement any component of the transaction system 100 as described herein. For example, a node 210 of the blockchain network 110 and/or a user terminal 240 may be implemented on the computing device 700, via its hardware, software program, firmware, or a combination thereof. Although only one such computing device is shown, for convenience, the computer functions relating to the transaction system 100 as described herein may be implemented in a distributed fashion on a number of similar platforms, to distribute the processing load.

The computing device 700 may include a COM port 750 connected to and from a network connected thereto to facilitate data communications. The computing device 700 may also include a processor 720 that is configured to execute instructions. The instructions may include, for example, routines, programs, objects, components, signals, data structures, procedures, modules, and functions, which perform particular functions described herein. In some embodiments, the processor 720 may process information related to an energy transaction in the transaction system 100. For example, the processor 720 may endorse a transaction proposal based on a smart contract. In some embodiments, the processor 720 may include one or more hardware processors, such as a microcontroller, a microprocessor, a reduced instruction set computer (RISC) , an application specific integrated circuits (ASICs) , an application-specific instruction-set processor (ASIP) , a central processing unit (CPU) , a graphics processing unit (GPU) , a physics processing unit (PPU) , a microcontroller unit, a digital signal processor (DSP) , a field programmable gate array (FPGA) , an advanced RISC machine (ARM) , a programmable logic device (PLD) , any circuit or processor capable of executing one or more functions, or the like, or any combinations thereof.

The computing device 700 may further include an internal communition bus 710, differet types of program storage and data storage including, for example, a disk 770, and a read-only memory (ROM) 730, or a random access memory (RAM) 740. The exemplary computing device may also include program instructions stored in the ROM 730, RAM 740, and/or another type of non-transitory storage medium to be executed by the processor 720. The methods and/or processes of the present disclosure may be implemented as the program instructions. The computing device 700 also includes an I/O component 760, supporting input/output between the computing device 700 and other components. The computing device 700 may also receive programming and data via network communications.

Merely for illustration, only one processor is illustrated in FIG. 7. However, it should be noted that the computing device 700 in the present disclosure may also include multiple processors. Thus operations and/or method operations performed by one processor as described in the present disclosure may also be jointly or separately performed by the multiple processors. For example, if in the present disclosure a processor of the computing device 700 executes both operation A and operation B, it should be understood that operation A and operation B may also be performed by two different processors jointly or separately in the computing device 700 (e.g., the first processor executes operation A and the second processor executes operation B, or the first and second processors jointly execute operations A and B) .

FIG. 8 is a schematic diagram illustrating exemplary hardware and/or software components of a mobile device 800 according to some embodiments of the present disclosure. In some embodiments, a user terminal 240 may be implemented on the mobile device 800. As illustrated in FIG. 8, the mobile device 800 may include a communication platform 810, a display 820, a graphics processing unit (GPU) 830, a central processing unit (CPU) 840, an I/O 850, a memory 860, and a storage 890. In some embodiments, any other suitable component, including but not limited to a system bus or a controller (not shown) , may also be included in the mobile device 800.

In some embodiments, a mobile operating system 870 (e.g., iOS ^TM, Android ^TM, Windows Phone ^TM, etc. ) and one or more applications 880 may be loaded into the memory 860 from the storage 890 in order to be executed by the CPU 840. The applications 880 may include a browser or any other suitable mobile apps for receiving and rendering information relating to the transaction system 100. In some embodiments, the applications 880 may include an application designed for energy transaction as described elsewhere in this disclosure (e.g., FIG. 2 and the relevant descriptions) . User interactions with the information stream may be achieved via the I/O 850 and provided to the blockchain network 110 and/or other components of the transaction system 100 via a network.

To implement various modules, units, and their functionalities described in the present disclosure, computer hardware platforms may be used as the hardware platform (s) for one or more of the elements described herein. A computer with user interface elements may be used to implement a personal computer (PC) or any other type of work station or terminal device. A computer may also act as a server if appropriately programmed.

FIG. 9A and FIG. 9B are schematic diagrams illustrating exemplary predicted energy demand of a grid element at a first predetermined time according to some embodiments of the present disclosure.

In some embodiments, the blockchain network 110 may predict an energy demand of one or more grid elements of the blockchain network 110 at a first predetermined time. The predicted energy demand may help the grid element (s) to understand its future demand and/or make an energy plan accordingly. In addition, the predicted energy demand may provide a basis for the operation of the blockchain network 110. The first predetermined time may refer to any future time point or period with respect to the present moment. For example, the first predetermined time may be the next year, the next half a year, the next month, or the next week with respect to the present moment.

In some embodiments, the blockchain network 110 may predict a demand of various types of energy, such as wind energy, fuel energy, hydroelectric power, nuclear energy, marine energy, osmotic energy, biomass energy, geothermal energy, external energy that is supplied by another grid element of the blockchain network 110, energy that is traded based on a long-term smart contract (e.g., an annual smart contract) , energy that is traded based on based on a short-term smart contract (e.g., a monthly smart contract) , or the like, or any combination thereof. Additionally or alternatively, for a certain type of energy, the blockchain network 110 may predict an amount of the energy needed by the grid element at the first predetermined time, an amount of token traded by the grid element at the first predetermined time, or the like, or any combination thereof.

In some embodiments, the predicted energy demand of a grid element may be determined by at least one node 210 of the blockchain network 110. The at least one node 210 may obtain first historical energy consumption information related to the grid element, and predict an energy demand of the grid element at the first predetermined time based on the first historical energy consumption information.

In some embodiments, the first historical energy consumption information may include, for example, an amount of energy consumed by the grid element during a historical time period (e.g., every day in the last year) , a price of the consumed energy during the historical time period (e.g., every day in the last year) , or the like, or any combination thereof. In some embodiments, the at least one node 210 may predict the energy demand based on the first historical energy consumption information by taking one or more other factors into consideration. Exemplary factors may include weather, a temporal factor, an emergency, an energy policy or regulation, or the like, or any combination thereof. For example, certain types of whether, such as rain, snow, wind, smog, hail may affect user’s demand for electricity. As another example, user’s demand for fuel gas may increase when a festival or a particular season (e.g., winter) is coming. These factors may be considered by the at least one node 210 in the prediction of the user demand. In some embodiments, the at least one node 210 may predict the user demand according to an algorithm, such as a Bayesian Ridge Regression algorithm, a Linear Regression algorithm, an Elastic Mesh Regression algorithm, a Support Vector Machine Regression algorithm, a Gradient-enhanced Regression algorithm, or the like, or any combination thereof.

After the predicted energy demand is determined, the at least one node 210 may transmit it to the user terminal 240 associated with the grid element for display. The user terminal 240 may display the predicted energy demand in any form, such as word, number, character, graph (e.g., a table, a curve) , image, voice, or the like, or any combination thereof. Merely by way of example, as shown in FIGs. 9A and 9B, the horizontal axis represents month and the vertical axis represents the amount of electricity. In FIG. 9A, the solid curve 910 represents the actual amount of electricity consumed by the grid element during January to July. The dotted curve 920 represents a predicted amount of electricity needed by the grid element during July to August. In FIG. 9B, the solid curve 920 represents a predicted amount of energy needed by the grid element during January to August.

FIG. 10A and FIG. 10B are schematic diagrams illustrating exemplary settlement results of a historical energy consumption of a grid element according to some embodiments of the present disclosure.

In some embodiments, the blockchain network 110 may settle a historical energy consumption of one or more grid elements of the blockchain network 110 at a second predetermined time. The settlement result may provide a basis for the grid element (s) to understand its pass energy consumption. The second predetermined time may refer to any past time point or period with respect to the present moment. For example, the second predetermined time may be the last year, the last quarter, the last month, or the last week with respect to the present moment.

In some embodiments, the blockchain network 110 may settle a historical consumption of various types of energy, such as wind energy, fuel energy, hydroelectric power, nuclear energy, marine energy, osmotic energy, biomass energy, geothermal energy, external energy that is supplied by another grid element of the blockchain network 110, energy that is traded based on a long-term smart contract (e.g., an annual smart contract) , energy that is traded based on based on a short-term smart contract (e.g., a monthly smart contract) , or the like, or any combination thereof. Additionally or alternatively, for a certain type of energy, the blockchain network 110 may settle an amount of the energy consumed by the grid element at the second predetermined time, an amount of token traded by the grid element at the second predetermined time, or the like, or any combination thereof.

In some embodiments, the historical energy consumption settlement may be performed by at least one node 210 of the blockchain network 110. The at least one node 210 may obtain second historical energy consumption information related to the grid element. The second historical energy consumption information may include, for example, an amount of energy consumed by the grid element during a historical time period (e.g., every day in the last year) , a price of the consumed energy during the historical time period (e.g., every day in the last year) , or the like, or any combination thereof. The at least one node 210 may settle a historical energy consumption of the grid element at the second predetermined time based on the historical energy consumption information. Merely by way of example, a node 210 may obtain the amount of electricity consumed by a grid element every day during last year, and settle the amount of electricity consumed by the grid element every month during last year.

After the settlement result is determined, the at least one node 210 may transmit it to the user terminal 240 associated with the grid element for display. The user terminal 240 may display the settlement result in any form, such as word, number, character, graph (e.g., a table, a curve) , image, voice, or the like, or any combination thereof. Merely by way of example, as shown in FIG. 10A, the horizontal axis represents month and the vertical axis represents the amount of electricity consumed by the grid element. Each column represents a total amount of electricity consumed by the grid element in a month. The electricity consumed by the grid element in a month may include a portion 1010 that was traded based on a long-term smart contract (e.g., an annual smart contract) and a portion 1020 that was traded based on a short-term smart contract (e.g., a monthly smart contract) .

As shown in FIG. 10B, the horizontal axis represents month and the vertical axis represents the amount of token traded by the grid element. The curve 1030 represents the amount of token traded according to a short-term smart contract (e.g., a monthly smart contract) during January to December. The curve1040 represents the amount of token traded according to a long-term smart during January to December.

It should be noted that the above description is merely provided for the purposes of illustration, and not intended to limit the scope of the present disclosure. For persons having ordinary skills in the art, multiple variations and modifications may be made under the teachings of the present disclosure. However, those variations and modifications do not depart from the scope of the present disclosure.

Having thus described the basic concepts, it may be rather apparent to those skilled in the art after reading this detailed disclosure that the foregoing detailed disclosure is intended to be presented by way of example only and is not limiting. Various alterations, improvements, and modifications may occur and are intended to those skilled in the art, though not expressly stated herein. These alterations, improvements, and modifications are intended to be suggested by this disclosure and are within the spirit and scope of the exemplary embodiments of this disclosure.

Moreover, certain terminology has been used to describe embodiments of the present disclosure. For example, the terms “one embodiment, ” “some embodiments, ” and/or “some embodiments” mean that a particular feature, structure or characteristic described in connection with some embodiments is included in at least one embodiment of the present disclosure. Therefore, it is emphasized and should be appreciated that two or more references to “some embodiments, ” “one embodiment, ” or “an alternative embodiment” in various portions of this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures or characteristics may be combined as suitable in one or more embodiments of the present disclosure.

Further, it will be appreciated by one skilled in the art, aspects of the present disclosure may be illustrated and described herein in any of a number of patentable classes or context including any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof. Accordingly, aspects of the present disclosure may be implemented entirely hardware, entirely software (including firmware, resident software, micro-code, etc. ) or combining software and hardware implementation that may all generally be referred to herein as a "block, " “module, ” “engine, ” “unit, ” “component, ” or “system. ” Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer-readable media having computer readable program code embodied thereon.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including electromagnetic, optical, or the like, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that may communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable signal medium may be transmitted using any appropriate medium, including wireless, wireline, optical fiber cable, RF, or the like, or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present disclosure may be written in a combination of one or more programming languages, including an object-oriented programming language such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C#, VB. NET, Python or the like, conventional procedural programming languages, such as the “C” programming language, Visual Basic, Fortran 1703, Perl, COBOL 1702, PHP, ABAP, dynamic programming languages such as Python, Ruby, and Groovy, or other programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN) , or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider) or in a cloud computing environment or offered as a service such as a software as a service (SaaS) .

Furthermore, the recited order of processing elements or sequences, or the use of numbers, letters, or other designations, therefore, is not intended to limit the claimed processes and methods to any order except as may be specified in the claims. Although the above disclosure discusses through various examples what is currently considered to be a variety of useful embodiments of the disclosure, it is to be understood that such detail is solely for that purpose, and that the appended claims are not limited to the disclosed embodiments, but, on the contrary, are intended to cover modifications and equivalent arrangements that are within the spirit and scope of the disclosed embodiments. For example, although the implementation of various components described above may be embodied in a hardware device, it may also be implemented as a software-only solution-e.g., an installation on an existing server or mobile device.

Similarly, it should be appreciated that in the foregoing description of embodiments of the present disclosure, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure aiding in the understanding of one or more of the various embodiments. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed subject matter requires more features than are expressly recited in each claim. Rather, claimed subject matter may lie in less than all features of a single foregoing disclosed embodiment.

Claims

A system for energy grid transaction, comprising:

a plurality of nodes, the plurality of nodes forming a blockchain network, each of the plurality of nodes being configured to communicate with each of other nodes of the plurality of nodes;

a user terminal configured to communicate with the blockchain network, the user terminal being associated with a grid element registered in an energy grid, wherein:

the plurality of nodes including at least one first node, each of the at least one first node is configured to receive a transaction proposal for energy from the user terminal, generating an endorsement result by endorsing the transaction proposal according to a smart contract, and transmit the endorsement result to the user terminal,

the user terminal is configured to generate a transaction based on the endorsement result received from each of the at least one first node, and transmit the transaction to at least one second node of the plurality of nodes, and

the at least one second node is configured to order the transaction and generate a block encoding the transaction.
The system of claim 1, wherein:

the at least one second node is further configured to transmit the block to at least one third node of the plurality of nodes, each of the at least one third node storing a distributed ledger and being configured to:

validate the transaction to generate a validation result, and

in response to the validation result that the transaction is valid, write the transaction into the leger.
The system of claim 2, wherein each of the at least one third node is further configured to transmit a notification regarding the validation result to the user terminal.
The system of any one of claims 1 to 3, wherein the transaction proposal includes at least one of an ID of a user of the user terminal, a digital signature of the user, a time stamp, an ID of the smart contract corresponding to the transaction proposal, a type of the energy to be traded, an amount of the energy, a transaction method, or a transaction price of the energy.
The system of claim 4, wherein the price of the energy is represented by a number of tokens, each token representing a value.
The system of any one of claims 1 to 5, wherein the smart contract is stored in each of the at least one first node.
The system of any one of claims 1 to 6, wherein:

the smart contract is based at least in part on data related to the smart contract inputted by a user via the user terminal, or

the smart contract is selected from a plurality of predefined smart contracts stored in each of the at least one first node.
The system of any one of claims 1 to 7, wherein at least one node of the plurality of nodes is configured to:

obtain first historical energy consumption information related to the grid element;

predict, based on the first historical energy consumption information, an energy demand of the grid element at a first predetermined time; and

transmit the predicted energy demand to the user terminal for display.
The system of claim 8, wherein the predicting the energy demand of the grid element at the first predetermined time is performed based on at least one of a Bayesian ridge regression algorithm, a linear regression algorithm, an elastic mesh regression algorithm, a support vector regression algorithm, or a gradient boost regression tree algorithm.
The system of any one of claims 1 to 7, wherein at least one node of the plurality of nodes is configured to:

obtain second historical energy consumption information related to the grid element;

settle, based on the second historical energy consumption information, a historical energy consumption of the grid element at a second predetermined time; and

transmit the historical energy consumption to the user terminal for display.
The system of any one of claims 1 to 10, wherein the energy is at least one of electric energy, solar energy, wind energy, fuel energy, hydroelectric power, nuclear energy, marine energy, osmotic energy, biomass energy, or geothermal energy.
The system of any one of claims 2 to 11, each of the at least one third node is further configured to store state information related to the blockchain network.
A method for energy grid transaction implemented on a plurality of nodes and a user terminal, the plurality of nodes forming a blockchain network, each of the plurality of nodes being configured to communicate with each of other nodes of the plurality of nodes, the user terminal being configured to communicate with the blockchain network and associated with a grid element registered in an energy grid, the method comprising:

by each of at least one first node of the plurality of nodes, receiving a transaction proposal for energy from the user terminal, generating an endorsement result by endorsing the transaction proposal according to a smart contract, and transmitting the endorsement result to the user terminal;

by the user terminal, generating a transaction based on the endorsement result received from each of the at least one first node, and transmitting the transaction to at least one second node of the plurality of nodes; and

by the at least one second node, ordering the transaction and generating a block encoding the transaction.
The method of claim 13, further comprising

by the at least one second node, transmitting the block to at least one third node of the plurality of nodes, wherein each of the at least one third node stores a distributed ledger;

by each of the at least one third node, validating the transaction to generate a validation result, and writing the transaction into the leger in response to the validation result that the transaction is valid.
The method of claim 14, further comprising:

by each of the at least one third node, transmitting a notification regarding the validation result to the user terminal.
The method of any one of claims 13 to 15, wherein the transaction proposal includes at least one of an ID of a user of the user terminal, a digital signature of the user, a time stamp, an ID of the smart contract corresponding to the transaction proposal, a type of the energy to be traded, an amount of the energy, a transaction method, or a transaction price of the energy.
The method of claim 16, wherein the price of the energy is represented by a number of tokens, each token representing a value.
The method of any one of claims 13 to 17, wherein the smart contract is stored in each of the at least one first node.
The method of any one of claims 13 to 18, wherein:

the smart contract is based at least in part on data related to the smart contract inputted by a user via the user terminal, or

the smart contract is selected from a plurality of predefined smart contracts stored in each of the at least one first node.
The method of any one of claims 13 to 19, further comprising:

by at least one node of the plurality of nodes,

obtaining first historical energy consumption information related to the grid element;

predicting, based on the first historical energy consumption information, an energy demand of the grid element at a first predetermined time; and

transmitting the predicted energy demand to the user terminal for display.
The method of claim 20, wherein the predicting the energy demand of the grid element at the first predetermined time is performed based on at least one of a Bayesian ridge regression algorithm, a linear regression algorithm, an elastic mesh regression algorithm, a support vector regression algorithm, or a gradient boost regression tree algorithm.
The method of any one of claims 13 to 19, further comprising:

by at least one node of the plurality of nodes,

obtaining second historical energy consumption information related to the grid element;

settling, based on the second historical energy consumption information, a historical energy consumption of the grid element at a second predetermined time; and

transmitting the historical energy consumption to the user terminal for display.
The method of any one of claims 13 to 22, wherein the energy is at least one of electric energy, solar energy, wind energy, fuel energy, hydroelectric power, nuclear energy, marine energy, osmotic energy, biomass energy, geothermal energy.
The method of any one of claims 14 to 23, wherein each of the at least one third node is further configured to store state information related to the blockchain network.