Project Description & Conceptual Architecture
With consumers of electricity now also becoming producers at a higher rate, more imbalance is created on the net. To maintain security of supply the imbalance should be kept within the limits of the grid. Currently the transmission system operator (TSO: Tennet in Netherlands) is responsible for maintaining this balance. A problem arises when the production becomes more and more decentralized, and the balancing is still the duty of a centralized body, it becomes harder to respond on the highly fluctuating consumption and production of the different actors.
The aim of this project is to design a decentralized market and a so called 'smart grid' where participants of the smart grid can dynamically match their supply and demand to minimize imbalances.
To create a useful design, the system should be able to be deployed in co-operation with the current electrical grid as it unrealistic to expect major changes in the grid topology in the forseeable future. The grid is currently laid out in a manner where several households (1 or more streets) are clustered together sharing a physical cable; the mains grids (220V). These clustered cables join at small brickhouse-substations spread out through the city. These substations are clustered together on a 10KV network, where one cluster roughly serves a city. Between nearby cities a 50KV net grid is clustering those together, from there they are clustered on a 110 -150 KV grid and again at a 380KV grid (which also connects with neighboring countries). In the current situation the grid is balance by the TSO, who buys capacity to up- or downregulate the consumption or production at companies spread out over several levels of the grid, and does so when required.
For balancing the grid matching consumption and production at the highest level is enough. Even when nationwide balance is achieved overload can happen due to unreasonably large imbalances on lower levels. Therefor we believe that balancing should, in the first place, happen within same cluster (e.g. a single street) before propagating it up to a higher level (e.g. district or city). When looking at an example of at the lowest, the spikey behavior of a single household is smoothened out by combining the households per cluster, and the smart grid aims to spread out the load equally over time. The remaining imbalance is then propagated to a higher level where bigger players (which more capacity but lower flexibility) can partake in the balancing game. For every step to a higher level the peaks become smoother and more predictable, which is very desirable for the big powerplants that will have to supply the energy in moments of energy shortage.
To enable the actual balancing between the participants of the smart grid (which will be called clients from now on) a platform must be offered to gain knowledge of the current state, the expected state and to perform reach agreements on energy exchanges. For this project we will explore the possibilities of using a blockchain for providing such a platform.
As discussed earlier, the focus should first lie on balancing within a single cluster, therefor there is no need for connecting every client to every other client. This creates the possibility of creating a blockchain per cluster instead of having to design a blockchain for all households in the system, which reduces the amount of transactions per second per blockchain significantly.
We envision a future where a software agent (possibly embedded in the smart meter) would communicate with blockchain on the client's behalf to gain knowledge about the state of his cluster of the grid. For every given interval it would submit the current consumption & production, expected consumption & production and any consumption & production it is willing to trade. Based on the amount of production and consumption within a cluster trades may or may not be made. The ability of choosing to charge or discharge an electric car if the price is right can be seen as an example of trading consumption & production.
The knowledge per cluster will then be aggregated and propagated as a single entry up to a higher level blockchain, where bigger parties can join the energy balancing game. The aggregation implies that individual information is lost when propagating to a higher level. However, this does not have to be a problem as the individuals in the cluster already did their best to solve the imbalance the best they could and the main task is now to balance out the remaining imbalance.
By following the physical lay-out for clustering the nodes we end up with a structure that could be visualized as a tree structure where the dataflows from node to node are only through their parent. A figure depicting such a tree is given in Figure 1. Here the circles containing the letter 'N' are the nodes that host the blockchain, the black symbols depict the clients (which can be households, industries and companies specialized in balancing).
Figure 1: A possible data structure with a blockchain per cluster.
Although the nodes in the figure are clustered per blockchain they don't physically need to be, and a single node could possibly even serve multiple independent blockchains.
As high temporal-resolution energy data can be a huge threat to the privacy of the client security of the network should be considered. One of the considerations is that the clients will not maintain a local copy of the blockchain, all the communication must be done through the nodes. If the authentication system is good enough, no client can access data he is not allowed to. If an energy company wants to bill a certain client (Because they have an agreement) the client can appoint and revoke access to the monthly, quarterly or yearly data. With these permissions stored in the blockchain, the company can request the required data through the node, and only get this data when the clients explicitly allowed this. When moving data to a blockchain at a higher level the data is implicitly anonymized due to aggregation of multiple households to a single entry.
It is also an option to explicitly enforce anonymity and ensuring that two transactions of the same client cannot be traced back to a single origin. This however, adds increased complexity to local energy trading. If a client promises to behave in a certain way (e.g. produce or deliver a certain amount of energy) how can one verify that the client delivered when transactions can't be linked to this single client?
When aiming to balance the entire electricity grid, everybody connected to the grid should be able to join the platform. For the Netherlands alone, this means that platform should support up to around 8 million households. In this design several nice features are in place to increase scalability. Even when having 8 million clients connected to the platform, there is no single blockchain that has to handle this amount of data on its own. Per blockchain on level h all the entries per time slot will be aggregated and a single entry will be send to a single blockchain on level h-1. Thus for every level the data moves up, the amount of transactions per level will be reduced. To reduce the amount of transactions per second even more it would be possible to reduce the time resolution on the higher levels as the parties with bigger capacities will not be able to respond as fast as the smaller more flexible parties on lower levels.
Layers
- Client Layer
- Blockchain Layer
- Visualisation Layer
High Level Diagram
Client Layer
In Scope:
- Ability to generate transaction of specific format – format TBC
- Ability to transmit the transaction to the Blockchain Layer
- Ability to combine smart meter reading, prediction agent output and trading agent output into one transaction as part of the transaction format
Out of Scope:
- Connection to real-life smart meters
- Intelligent generation of prediction agent output and trading agent output
Blockchain Layer
Blockchain Method and Platform:
- Ability to run permissioned blockchain:
- Ability to maintain similarity with the current physical infrastructure
- Ability to hold consensus servers accountable
- Ability to trace clients/users in the system
- Ability to run blockchain with BFT-based PoS design:
- Ability to reach the performance level required by the target field of implementation with limited number of nodes (e.g. to serve up to thousands of clients with only up to 20 nodes)
- In addition, BFT blockchains are per definition permissioned, requiring the sharing of identities amongst the servers, in support of the requirement related to permissioned blockchain
- Ability to be flexible over the blockchain application functionality so that any block/contract logic can be defined depending on the field of implementation
Blockchain integration with the Client Layer:
- Ability to receive transaction of specific format from the Client Layer
- Ability to add block to the blockchain dedicated to the Cluster L0
Blockchain functionality for Visualisation:
- Ability to provide data to the visualisation layer
Blockchain functionality for Cluster L0 Blockchain:
- Ability to maintain the logic of the blockchain – logic TBC
Blockchain functionality for Cluster L1:
- Ability to aggregate information for Cluster L0 Blockchain
- Ability to transmit transaction to the Cluster L1 blockchain
Out of scope:
- Security
- Anonymisation
- Smart Contracts
Visualisation Layer
- Ability to receive data from the blockchain layer
- Ability to visualise data
| Milestone | Planned Date | Client Layer | Blockchain Layer | Visualisation Layer |
|---|---|---|---|---|
| 1 | 08.12.2017 | • specify client layer design and technical landscape | • finalise platform and development tools selection (tendermint & python) • finalise infrastructure setup for nodes |
• research potential visualisation tools |
| 2 | 15.12.2017 | • put in place working components for the landscape (files, code, protocols, config, etc) • finalise the format of a transaction v1 and document |
• setup platform and development environment • test connection to the client layer • finalise design for blockchain application and document |
• select visualisation tool |
| 3 | 22.12.2017 | • prototype functionality that generates transaction | • prototype blockchain application • finalise data format for visualisation layer |
• prototype blockchain visualisation |
| 4 | 23.01.2018 | • finalise functionality that generates transaction • test and confirm ability to submit transactions to blockchain layer • document client layer |
• finalise blockchain application • document blockchain layer • (optional) Explore design for BC Cluster L0 aggregation |
• build visualisation layer and unit test • document visualisation layer |
| 5 | 30.01.2018 | • demonstration | • demonstration • (optinal)explore design for BC Cluster L0 communication to BC Cluster L1 |
•demonstration |
Client Layer
- Code and its implementation
- Technical documentation
- Description of tests
Blockchain Layer
- Code and its implementation
- Technical documentation
- Description of tests
Visualization Layer
- Code and its implementation
- Technical documentation
- Description of tests
Overall
- Project Report
- Demonstration