For a few decades, the idea of creating a faster, more decentralised web technology system which is less dependent on human interference has been a defining factor for database innovations, cue in the blockchain database, which is what cryptocurrencies are run on.
However, that is not the only use of this blockchain technology; renewable energy innovators know this. Implementing this new form of technology to execute contracts smartly to help manage energy needs seems to be the way forward.
The basic idea of the blockchain database technology is that data is introduced into a block with a specified intake capacity. Once that capacity is reached, data is rerouted to a new block that is continuously chained to the previous one. This is done chronologically so that whatever data comes in first is retained first.
The blockchain database is most commonly used to store information as a ledger of transactions for now, but many more aspects of this technology currently remain unexplored. Data entered into decentralised blockchains cannot be reversed, and so they can be view by anyone and are not controlled by any single entity.
Blockchain technology deals with the issues of security and trust in several ways. The major one is its almost impossible allowance for alteration without consensus due to hash codes’ chain reaction. Each block has created these hash codes, with the codes of the previous block and timestamps getting stored in the block following it continuously.
The ultimate goal is to create a database where digital information can be recorded and distributed without the possibility of this information being altered or edited yet remaining completely accessible.
How Does Smart Contract Work?
So far, understanding the blockchain technology has been simple enough, so will smart contracts.
These are contracts that can be digitally executed when predetermined terms and conditions are met. They are lines of code that have been previously embedded to carry out an agreed-upon command when triggered.
According to IBM blogs “The benefits of smart contracts are most apparent in business collaborations, in which they are typically used to enforce some type of agreement so that all participants can be certain of the outcome without an intermediary’s involvement.”
To wholly understand how smart contracts work here is an example. suppose you’ve ever gone through the hassle of buying a new home or getting a loan to start a business and have gotten easily turned off by all the hoops, checks and rechecks you have to be put through to get a nod from your service provider before the actual process begins. In that case, you’ll understand the stress of the situation which can drag on for months at a time, leaving you in more distress than when you started. Well, smart contracts cut out all that hassle. You can almost liken it to switching from a 1994 Macintosh to a 2021 smartwatch.
Entering and re-entering personal information, verifying identity, interacting with different intermediaries, and unnecessary fees and commissions at every step are entirely removed in smart contracts. So this means there are less third party interferences and much smoother executions of contract agreements where all parties are abreast of all details, changes and conclusions as they occur. A huge preference for companies and organisations alike.
How Can Blockchain Smart Contracts Improve The Energy Sector?
With energy evolving before our eyes from the era of fossil fuels and their effects on the earth to renewable energy sources and energy storage and management, it would be wise to seek out an innovative way of reducing the hassle of the management aspect with the blockchain technology and smart contracts.
Bridging the trust gap is a critical factor of smart contracts. If your information is already stored on the blockchain, it is readily available for review and decisions can be made about agreements, payments and deals within shorter periods.
Here are some key benefits of smart contracts:
- Trust: because Smart contracts work with preinstalled code they are executed once predetermined rules are adhered to without third party involvement and, transparency is evident, all information is shared with involved participants
- Security: blockchain technology works with code, all data is encrypted making it increasingly difficult for hackers to have a field day because all records are linked to previous and subsequent records with time stamps and hash codes making any alteration completely affect the whole database, to change anything would involve changing all the information on the blockchain
- Accuracy: without excessive human interference the execution of smart contract orders happens seamlessly and according to exact requests entered into the blockchain, so there is less of a possibility of human error
- Speed: information on the blockchain is automated saving you the stress of unending paperwork or manually correcting and filling documents every time a contract is needed, it does the job in half the time traditional contracts would take
- Immutability: in blockchain, more blocks can always be added but not removed, so records of every transaction are permanent, this increases trust between all participants
- Cost-saving: with the expulsion of unnecessary intermediaries less money will be needed to complete agreements or execute contracts, this will only happen when all other benefits are fulfilled and trusted
Smart contracts are executed through codes that follow the “if/when/then” statements stored on the blockchain database. In the energy sector accuracy, trust, security and saving cost is paramount, and these are the major advantages of smart contracts linked to the blockchain.
In contemporary energy management systems, which usually involve the generation of orders, trade compliance, managing orders, price delivery, exchange execution and settlement accounting, are all time-consuming. The lack of flexibility allows for too many complications tying in several intermediaries.
As a grid operator, smart contracts and decentralised software guaranteed by blockchain technologies can be utilised to create a seamless, secure and efficiently distributed energy system promising to solve at least 80% of these highlighted pitfalls.
One of the reasons for the high popularity of cryptocurrencies is that they allow a decentralized economic system. This point is unanimously considered pivotal in the crypto world, where the worst insult for a project is calling it ‘centralized’. However, the definition of decentralization is often hardly understood. Even worse, a recent study shows that cryptocurrencies are not so decentralized as one might think, considering that the top four miners in Bitcoin and the top three miners in Ethereum control more than 50% of the hash rate.
Decentralization is often explained in terms of the communication architecture of a network, and a distinction is usually made between decentralized and distributed networks. This very famous picture explains the differences eloquently:
The picture is somehow self-explanatory, but we can try to give a tentative definition of the three architectures:
- centralized architecture: information passes from a single node
- decentralized architectures: not all information passes from a single node
- distributed architectures: nodes communicate only with their neighbors
This (very personal) definition makes distributed architectures a subclass of decentralized architectures.
This picture was firstly published in 1964 by Paul Baran, a pioneer in the field of computer networks. When Baran published his work, he was considering distributed networks for increasing the resilience of the national communication structure in the context of a possible atomic war:
…it can be shown that highly survivable system structures can be built, even in the thermonuclear era
— Baran, Paul. “On distributed communications networks.” IEEE transactions on Communications Systems 12.1 (1964): 1–9.
From this point of view, in which the communication network is operated by a trusted entity (the government) and the architecture has the only purpose to guarantee communication, there is no further need to consider decentralization under other aspects. In this post on the meaning of decentralization, Vitalik Buterin explains why, for cryptocurrencies and distributed ledger technologies, there is the need to expand the definition of the decentralization grade of a system.
Briefly speaking, three key aspects can be considered:
- architectural decentralization: this coincides with the definition given by Baran. The system should be geographically dislocated in order to be robust against malicious attacks. The implicit assumption is that attacker’s costs are sublinear: destroying a very big central unit is cheaper than destroying thousands of smaller dislocated communication units.
- political decentralization: decisions concerning the protocols running the network should be made by several individuals/organizations with no concurrent interests in manipulating the network. This aspect is important once we exit from a ‘us’ against ‘them’ mind setting, in which the network operator is trusted and the system must be protected against outsider’s attacks. Note that in the case of cryptocurrencies cartels formation is completely expected — Vlad Zamfir. The History of Casper — Chapter 4.
- logical decentralization: this concerns the ‘state’ of the system, where ‘state’ means all the data available through the network. The bittorrent platform is logically decentralized, since the network’s data is stored by the peers, each of them storing only a part of the whole available data. The Ethereum network, and DLTs in general, are logically centralized, since it’s desirable that all the peers see a coherent (the same) network state at any time. This coherency comes at the cost of highly redundant data structures and at the course of the CAP theorem: if the system gets partitioned, only one property among consistency and availability can be guaranteed.
Now that we have a good grasp on the meaning of, and problems connected to, (de)centralized networks, we can start to discuss decentralized architectures for energy markets.
More and more renewables are being installed in the distribution grid, especially photovoltaics. Solar panels are highly stochastic energy sources with deep volatility. This volatility calls for an increased flexibility of the demand and creates a sweet spot for the creation of energy communities implementing local energy markets. These markets will have 3 kinds of participants:
- Local producers, who can sell their excess energy at higher prices
- Consumers with flexible loads (e.g. water heaters, heat pumps, EV chargers), who can get a discount for load shifting
- Battery owners, who can sell their storage capability
These three actors could have different motivations in participating to such energy community, among which:
- A reduction of their electricity bills thanks to the increased self-consumption of the community. The energy communities will also be able to sell their flexibility to distribution system operators, generating additional profits for their members.
- An increase in the share of locally produced clean energy that they consume.
Let us focus on the specific problem of the choice of the architecture for such a market design.
First of all, we don’t have to start from scratch, the electrical grid is also a network with its own architecture. The existing Infrastructure is massive. It was developed by billions of dollars and can be divided essentially into:
- Electrical transmission and distribution network (cables, transformers, capacitor banks, FACTS, etc…)
- Communication infrastructure for metering and control (PLC, optical fibers, etc.)
The network architecture of the electric power grid is also peculiar. In particular, it is divided into different voltage levels. The choice of the voltage level is a function of:
- The distance to be covered
- The amount of power that needs to be transported
Per unit of length high voltage lines are more expensive than medium and low voltage ones, but the amount of power they can transport and the distance they can cover is much higher, thanks to lower losses. Indeed, raising the voltage by a factor of 10 reduces the current by a corresponding factor of 10 and therefore the RI² losses by a factor of 100.
In distribution systems, once the electricity approaches the point of consumption the voltage is gradually decreased thereby decreasing the cost of the lines and reducing the possible dangers in case of a short circuit.
In the above figure, we can see the high voltage (HV) and medium voltage (MV) lines in the region around Hive Power’s headquarter, ranging from 380 kV (red lines) to 50 kV (blue lines).
The low voltage (LV) network, which is much more ubiquitous, like the one shown in the above figure. In the most common case, the topology of the low voltage network is radial, that means it has a simple tree-like structure.
This structure naturally partitions the system. From the physical point of view, the effects of a LV network on the upper MV level, can be taken into account only by means of the total power at the transformer. In other words, it is not required to know the power consumption of all the buildings in the LV network at a given time to effectively control the MV level, nor it is required that a prosumer located in the LV A knows about all the energy produced or consumed by all the prosumers in the LV B to effectively exchange energy.
And now a very important point:
“The mechanism design of new energy markets must explicitly consider the effect of traded energy on the electrical grid. The energy prices must reflect the state of the grid.”
This point is essential for understanding how we view the market and its communication infrastructure. In the presence of distributed generation from renewable energy, e.g. PV, the power production gets highly synchronized. This synchronization is a possible hazard for the electrical grid, since it can overload electrical lines. Furthermore, power production from renewable energies is highly volatile, influencing the local power quality.
New energy markets are in charge of mitigating the effect of an increasing penetration of renewable generators in the electric grid. Common view among the scientific community is that this could be done by means of demand response programs, in which the energy price is changed dynamically, based on the state of the grid.
These considerations lead us to analyze another sub-class of decentralized architectures, which is a very good candidate for decentralized energy markets: hierarchical structures. Hierarchical structures are essentially tree-like structures, in which each node can be a terminal or a branching node. Terminal nodes are the ‘leaves’ of the tree, and have no downwards connections. In our energy markets, terminal nodes are single prosumers.
The picture above depicts an example of a hierarchical structure, in which the blue terminal nodes with a same parent node, are gathered together in a group. Note that this structure is sort of fractal, that is, a group can be seen as a single terminal node when seen from the upper level.
Back to the energy markets and decentralized systems!
How does this architecture fit into the aforementioned classification, and why does it make sense for decentralized energy markets? Let’s reconsider each point one by one:
- architecture: the architecture is geographically decentralized, but not fully distributed. That is, not all the nodes are equally important, from the point of view of an attacker which would like to make the whole system unavailable. Consider anyway that it is true also for the electric system. Furthermore, and more importantly, remember that the groups are decoupled, physically and logically. This means that, if for some reasons communication with the root node (the one located at the top level), is lost, prosumers in the communities in the lower levels can still effectively trade energy among peers in the same community.
- political: the hierarchical architecture make the branching nodes pivotal for the energy market to work. This empowers the owners of the branching nodes, with respect to simple prosumers. In order to eliminate this issue, we can introduce a governance system regulated by smart contracts.
- logical: the hierarchical architecture does not influence logical (de)centralization per se. Anyway, remember that the system we want to operate is decoupled, and physical effects can be taken into account by means of aggregated power on upper levels. That is, both energy trading and grid control are possible if information is aggregated at each branch of the structure. This aggregation would both avoid unnecessary information flows and preserve the privacy of the prosumers: only aggregated information about energy consumption is available at higher levels of the structure; furthermore, even prosumers belonging to the same groups have only aggregated informations about each others.
Hierarchical structures have also another peculiar aspect which is strictly related to mechanism design, a field of economics and game theory which aims at building market rules that induce a desired effect on the market equilibria. For instance, the CASPER protocol of Ethereum is seen by its creators as the result of applying mechanism design to cryptoeconomy.
Designing a market that turns competition into cooperation
One of the most celebrated outcomes of mechanism design is the revelation principle, that states that:
If the market is incentive compatible, we can restrict the study to the situation in which each participant is willing to disclose its private information.
This means that no agents would have incentives in lying about their power forecasts nor expected utility of using a certain amount of energy. Let’s do an example to clarify the implications.
Consider that each market player would adopt an optimal strategy (in terms of outcomes) given his private information. A player could lie in reporting his private information if he finds he has some advantages in doing so. For example, imagine we have designed a market in which prosumers pay a price proportional to their consumption and, if they consume more than the average, they pay an additional fee. If prosumer A declares he’s going to consume a lot of energy in the next market period, the other prosumers could increase their consumption plans, since they believe to be under-the-average consumers. In the next step, prosumer A consumes much less than the one he had previously declared, but there is no time for the other prosumers to synchronize again with updated information. As a result, A is now an under-the-average consumer. What is happened is that A, lying about his private information, has prevented the risk of paying the additional fee, to the detriment of the others.
How can this be avoided? In the simplest form, prosumers (leaf nodes) can agree to communicate their private information to a super-partes entity (their parent node), which would play the optimal strategy for them. Finding the optimal strategy generally involves solving a pre-defined optimization problem. The important thing is that each prosumers has previously agreed on how this optimal strategy is found, and that all of them consider the super-partes entity as trustful. In this case, prosumers have no interests in lying, since doing so they would incur in a payoff reduction, by definition!
In view of the above mentioned benefits, at Hive Power we decided to design our distributed energy market platform making use of aggregators. Of course these aggregators should either be trusted or, even better, auditable.
In my next posts I will discuss how we will:
- model the market in a dynamic and stochastic setting
- take into account grid constraints
- preserve user privacy
I will also discuss alternative solutions for the intra-group communication. Stay tuned!
At Hive Power we are enabling the creation of energy sharing communities where all participants are guaranteed to benefit from the participation, reaching at the same time a technical and financial optimum for the whole community.
As a consequence of the foreseen significant increase in stochastic generation in the electrical grid, the need for flexibility and coordination at demand side is expected to rise. Decentralized energy markets are among the most promising solutions allowing to boost coordination between production and consumption, by allowing even small actors to capitalize on their flexibility. The main purpose of Hive Power is to develop a blockchain-based platform to support groups of prosumers that want to create their own energy market. The core element of this framework is the so-called Hive, i.e. an implementation of an energy market based on blockchain technology (see our white paper on hivepower.tech to have detailed informations about Hive Power platform).
This article describes Demo Hive, the first testbed developed by our team and presented during the Energy Startup Day 2017 in Zurich, Switzerland on November 30th 2017. Practically, the demo is a simple but also meaningful case of a hive; it is constituted by a producer and a consumer, the so-called workers. A third element is the QUEEN, whose aim is to manage the interaction between the workers and the external grid and to track the measurements related to the power consumed/produced by the workers. The producer, following named SOLAR, simulates a photovoltaic plant with a nominal power of 5 kWp. Instead the other worker (LOAD) generates data about a load consumption. Fig. 1 shows the demo testbed.
Fig1: The Demo Hive testbed
Essentially, the main hardware components of Demo Hive are:
- two SmartPIs, one for each worker. This device is constituted by an acquisition board for the electrical measurements (voltages and currents) connected to a Raspberry Pi 3. In Fig. 1 the two workers are the black boxes on the bottom.
- A Raspberry Pi 3 in order to provide the Queen functionalities.
- A 5G router to provide the Internet connectivity and a WLAN inside the testbed.
One of the most meaningful aim of Demo Hive is to tokenize the produced/consumed energy and to save the related information on a blockchain. For that reason an ERC20-compliant smart contract was deployed on the Ropsten network in order to create a demo token, called DHT, which has the following fixed value:
- 1 DHT = 1 cts = 0.01 CHF
The basic idea of Demo Hive is that LOAD owns a certain amount of DHTs and sends part of them to the producers (typically SOLAR, but also the external grid through QUEEN) to buy energy. In the following chapter this aspects will be exhaustively described.
A set of applications runs on the aforementioned devices to actuate the Demo Hive platform, a part of them developed by Hive Power. In this article only the main behavior of the demo testbed will be described, avoiding to explain all the code in details. The following image reports the software interactions inside the demo and outside with the Ropsten network.
As written in our whitepaper, periodically the real Hive platform will save data about the tokenized energy on a blockchain. This is quite unconvenient in a demo testbed because the period can be too long. For that reason the demo software considers virtual days with a duration of just 10 minutes. This means the SOLAR worker produces in 10 minutes the same energy really performed in 24 hours. Similarly the power measurements, in a real application performed off-chain and usually acquired every 15 minutes, in Demo Hive are measured every 5 seconds. As shown in Fig. 2, during the virtual day of 10 minutes the power measurements are saved by the workers in QUEEN (black arrows) in an InfluxDB database, a time-series oriented DBMS commonly used in monitoring applications. When the simulated day ends, the workers energies are calculated and tokenized in DHTs considering the following static tariffs.
- Buy on grid: 20 cts/kWh
- Sell on grid: 5 cts/kWh
- Buy in the Hive: 10 cts/kWh
- Sell in the Hive: 10 cts/kWh
Consider that LOAD/SOLAR worker can only buy/sell energy. Instead QUEEN, managing the interface with the grid, is allowed to perform both the operations. At the end of a simulated day a tokenization algorithm tries to maximize the hive autarky using the following rules (see also Fig. 2):
IF 𝑬_𝑳𝑶𝑨𝑫>𝑬_𝑺𝑶𝑳𝑨𝑹 : LOAD buys 𝑬_𝑺𝑶𝑳𝑨𝑹 from SOLAR (10 cts/kWh) and 𝑬_𝑳𝑶𝑨𝑫−𝑬_𝑺𝑶𝑳𝑨𝑹 from QUEEN (20 CHF/kWh)
ELSE IF 𝑬_𝑺𝑶𝑳𝑨𝑹>=𝑬_𝑳𝑶𝑨𝑫 : SOLAR sells 𝑬_𝑳𝑶𝑨𝑫 to LOAD (10 CHF/kWh) and 𝑬_𝑺𝑶𝑳𝑨𝑹−𝑬_𝑳𝑶𝑨𝑫 to QUEEN (5 CHF/kWh)
Practically the workers exchange all the available energy in the hive, exploiting the more convenient tariffs.
Thus, the energies are tokenized in DHTs and the related tokens (as written before, 1 DHT = 1 cts) sent by buyers (LOAD or QUEEN) to sellers (SOLAR or QUEEN) according to the aforementioned algorithm. In Fig. 2 these operations are represented by the red and light blue arrows. The DHTs transfers are then saved on the Ropsten blockchain. This can be performed because on each demo device a geth client maintains a node synchronized to the Ethereum testnet network. In order to minimize the required disk space, the geth instances run the Ethereum light client protocol. The Ropsten accounts of the components are reported below:
- LOAD: 0x888d0aafc4d7c95fcaff9264d4bc2c1829a575be
- SOLAR: 0x3b5b6bbF5A14259bdF499f526A51aE7bF21c7476
- QUEEN: 0x7ab0c357cf3ae3c36b7ee8d4a84722a96790a6bd
As explained above, the Demo Hive testbed simulates “virtual” days with a duration of 10 minutes. During a single day the produced/consumed power of the two workers is saved every 5 seconds. At the end of the day (i.e. 10 minutes) the related energies are calculated, tokenized and saved on Ropsten network. In order to have days with both the aforementioned cases of the autarky algorithm (i.e. solar production > load consumption and solar production < load consumption) the following power profiles are taken into account for the workers:
- SOLAR: two profiles are considered, the former (following named CLEAR) with a significant production, related to a day without clouds. Instead the latter (following named CLOUDY) has a poor production, simulating an overcast day. The sequence of the profiles in the simulated days is a continuous alternation, i.e. after a CLEAR day there is a CLOUDY one, and so on.
- LOAD: a unique typical profile is taken into account as baseline, then every day a noise is added to it. As a consequence, during the simulated days the resulting profiles are always similar, but never equal.
Fig. 3 shows an example of two simulated days. It is simple to note the difference between the CLEAR and CLOUDY cases.
The profiles shown in Fig. 3 were performed during the Energy Startup Day 2017. Considering the first profile (CLEAR), it is simple to understand how the SOLAR production exceed the LOAD consumption. As a consequence, all the energy needed by LOAD is locally bought in the hive from SOLAR producer at the convenient Hive tariff (i.e. 10 cts/kWh). On the other hand, the remaining amount of produced energy not bought by LOAD will be sold by SOLAR on the grid with a less convenient tariff (i.e. 5 cts/kWh). Acting as described, the local energy exchanging is maximized and, consequently, the two workers realize to save/profit money taking advantage of the Hive tariffs.
In the second case (CLOUDY profile), the production is not able to cover all the consumption. Thus, LOAD has to buy part of the needed energy from the grid paying 20 cts/kWh.
At the end of the simulated day the savings/profits data are then tokenized and the related DHTs distributed by the consumer (e.g. LOAD in a CLOUDY case) to the producers (e.g. SOLAR and QUEEN in a CLOUDY case) in order to pay the used energy. In the following list the energy profits/costs in DHTs are reported comparing the cases of Demo Hive against a business as usual (BAU) situation, where the hive market does not exist (i.e. only the grid tariffs, 20/5 cts/kWh to buy/sell energy, are available).
- Solar revenues:
12:00-12:10 (CLEAR): HIVE = 432 DHT BAU = 254 DHT HIVE-BAU = 178 DHT
12:10-12:20 (CLOUDY): HIVE = 135 DHT BAU = 68 DHT HIVE-BAU = 67 DH
- Load costs:
12:00-12:10 (CLEAR): HIVE = 356 DHT BAU = 713 DHT HIVE-BAU = -357 DHT
12:10-12:20 (CLOUDY): HIVE = 590 DHT BAU = 725 DHT HIVE-BAU = -123 DH
It is easy to note how the saved/earned money of LOAD/SOLAR is much higher during the CLEAR day, being the solar production able to cover all the energy needed inside the hive. The following list reports the precise amounts:
- LOAD saves 3.57 CHF during CLEAR days
- LOAD saves 1.23 CHF during CLOUDY days
- SOLAR earns 1.78 CHF during CLEAR days
- SOLAR earns 0.67 CHF during CLOUDY days
The following URLs report the Ropsten transactions details related to the simulated days.
- TX_CLEAR_1: 356 DHTs sent by LOAD to SOLAR
- TX_CLEAR_2: 76 DHTs sent by QUEEN to SOLAR
- TX_CLOUDY_1: 455 DHTs sent by LOAD to QUEEN
- TX_CLOUDY_2: 135 DHTs sent by LOAD to SOLAR
The Demo Hive testbed implements a very simple case of hive. It is a significant starting point for the development of the complete framework, but some improvements have to to be implemented. The following list reports the most meaningful features still to develop.
- Prototype of a “blockchain-ready” meter: SmartPi device is based on a Raspberry Pi 3 board, a great hardware platform for prototyping and initial tests but not projected to be easily integrated in an industrial product. In order to develop a blockchain meter, naturally necessary in our framework, the idea of Hive Power is to take into account more industrial-oriented hardware platforms and using them to substitute the SmartPi devices.
- Power profiles: Currently the workers profiles are quite similar during the “simulated days” of 10 minutes. Practically there is a precise alternation of clear and overcast days for the SOLAR production. Regarding the LOAD, every simulated day a noise is added to the same predefined profile. In order to have a more realistic situation, new profiles have to be considered (e.g. two different LOAD profiles, the former for workdays and the latter related to the weekend)
- State channels: in our demo testbed, the power measurements are now acquired every 5 seconds and the related data saved in an database running on QUEEN. In order to have a fully decentralized approach, our idea is to handle power data using State Channels technology avoiding to use a local database.
- More workers: To have a more realistic simulation of a Hive energy market, the number of workers should be increased.
- Prosumer/Storage worker: Currently being in Demo Hive only a consumer (LOAD) and a producer (SOLAR), it will be meaningful to introduce prosumer and storage workers in order to have a complete market. It is interesting to consider that with storage systems it would be possible to implement load-shifting algorithms to maximize the costs savings.
- Dynamic tariffs: In Demo Hive only static tariffs are taken into account for the energy buying/selling. Clearly, this is not a realistic situation and consequently a dynamic system of tariffs has to be implemented.
The integration of IoT and Ethereum is emerging as a powerful solution for data management using the blockchain technology. Unfortunately, at present the speed and storage requirements of a typical IoT application exceed the capabilities of the public Ethereum blockchain. The reasons are mainly two, the former is the block time, currently too high to be able to track IoT data. The latter is the gas cost: each transaction has a cost on Ethereum, thus the global amount of gas paid for all the transactions would be highly expensive. As a consequence, currently an interface among the “fast” world of IoT and the “slow but decentralized” one of Ethereum is needed.
Raiden (https://raiden.network/) is a framework for the fast management of transactions. Being built as a off-chain solution, it provides a fast exchange of data among the Raiden nodes using the state channels technology, avoiding the long response time and the gas costs related to on-chain transactions. On the other hand, the starting and the end points of each Raiden state channel are tracked on the blockchain (currently only on Ropsten network) with the related initial and final balances.
In this article the procedure to install Raiden (https://raiden.network/) on a Raspberry Pi 3 is explained. I chose this well-known hardware platform because it is widely used for IoT applications. It is assumed that Raspbian Jessie 8 is the operating system running on the Raspberry Pi 3.
The installation steps can be summarized into the following list. For each point an explanation is reported together with the related bash commands.
- Step1: Installation of libraries and tools required by the following steps.
# sudo apt-get install geth pip cmake libboost-all-dev
- Step2: Creation of a temporary swap file to avoid memory overflows. The available memory in a Raspberry Pi 3 is 1 GB and ~20% of RAM is used by Raspbian and other processes. The remaining RAM is not sufficient for the following compilation processes, so a swap space has to be used. I performed some tests without swap, but I always encountered memory overflows. In the example below I created a swap file of 0.5 GB, enough for the compilations. Consider that after the following two steps the swap file can be deleted and so the space reallocated to the root partition.
# sudo dd if=/dev/zero of=/swap bs=1M count=512 # sudo mkswap /swap # sudo swapon /swap
- Step3: Installation from source of the tool Z3 (https://github.com/Z3Prover/z3), required by the solc compiler. On the Raspberry Pi this process was very long, about some hours.
# mkdir ~/software # cd ~/software # wget https://github.com/ethereum/solidity/releases/download/v0.4.16/solidity_0.4.16.tar.gz # unzip z3-master.zip # cd z3-master # python scripts/mk_make.py # cd build # make # sudo make install
- Step4: Installation from source of the Solidity compiler (solc). This software is required by Raiden but, unfortunately, currently no binary package is available for the hardware architecture of Raspberry Pi 3 (armv7). This is the cause of the compilations and, definitely, the main reason of this article. Under the computational point of view, also this step has a meaningful duration, although faster than Step3.
# cd ~/software # git clone --recursive https://github.com/ethereum/solidity.git # cd solidity-0.x.y # scripts/install_deps.sh # scripts/build.sh
- Step5: Installation of Raiden. The final step is much simpler than Step3 and Step4, being Raiden a set of Python scripts, thus no compilation is required.
# cd ~/software # git clone https://github.com/raiden-network/raiden.git # cd raiden-x.y # sudo pip install --upgrade -r requirements.txt # sudo python setup.py develop
Now all the tools are properly installed and we can start using them. Currently Raiden network is available only on Ropsten network, thus the first passage is to start geth in light mode (the unique I realized to launch on a Raspberry Pi) and sync it to the test network.
# geth --testnet --light --v5disc --cache 1024 --rpc --rpcport 8545 --rpcaddr 0.0.0.0 --rpccorsdomain "*" --rpcapi "eth,net,web3" console
Once the node is synced, a Ropsten account has to be created and an amout of at least 0.1 ETH assigned to it. After that we can start Raiden as shown below:
# raiden --keystore-path ~/.ethereum/testnet/keystore
To test if Raiden has been successfully installed, it is possible to query its REST interface with the following command and to check the result:
# curl -X GET http://127.0.0.1:5001/api/1/tokens [ “0x2d3632ea6f06b2aad472d3f8cf49eefd98b96d71”, “0x9aba529db3ff2d8409a1da4c9eb148879b046700”, “0x53c9884988058dd583d816aae9976775fb94b4a4”, “0x25a8004bd889a0c31e9382f50272e596bf5d8a88”, “0xa87d050d6ebbbabf1095d50c493a41a51f57a44e”, “0xc67f4b9a7592b43a474df44939c0630e24c414dd”, “0xbaa4589a1a49f722293360e352fed692e741442d”, “0xd7f14d6bff222c650e1ebd60fc4673c737c40134”, “0xd73860f000e675c15ca8b060da0128f5473b4d96”, “0xc90e57fe7da3b8f6c86e20f640dd9785c52906f7”, “0x683aca737b264ae43c91ea3196dd017b186b0e0b”, “0x78a9b00be464351471f73d3c26485fe0434c92dc”, “0xcd0d53a45cdda84fee9edb5874a7897ebdc9624e”, “0xf025f2ddb226684ab66df9fdf3928d053a237dce”, “0x79fc539d3207a172959d1cb6a73fae18621e96c8”, “0x3791165e88164c0256a652d746a4a60b11eacb93”, “0x583cbbb8a8443b38abcc0c956bece47340ea1367”, “0x4d55ca1059f95a77f5a88a80fff918f095136c2b”, “0x33511d2c9c1f05036e4b2aea602ac2a5028c113a”, “0x501a3ea063a97fcc76afba2b1779864c98ad89c8”, “0x0f114a1e9db192502e7856309cc899952b3db1ed”, “0xe987ea391d45b837f12601e0a8298779dc17d903” ]
If you find something similar, you have Raiden working on your Raspberry Pi 3, have fun!
In the latter years the world faced an amazing adoption of renewable energy sources, mainly solar and wind. Initially, the rapid advancement of these technologies was driven by strong incentive programs, first in Europe and therefore in the rest of the world; in parallel, technical improvements and economies of scale of manufacturers, mainly Asian, have allowed a rapid decline of renewable electricity costs.
Today, in different parts of the world, renewable energies are already cheaper than fossil fuels, but there are several cases where their adoption can be stalled by uncertain self-consumption rates of the energy produced. In fact, with current tariffs scheme, a very important factor for calculating the financial return of a new photovoltaic plant is the percentage of self-consumption. This is due to the big difference between the prices of energy purchased and sold to the local network, so without a significant energy consumption during the sunny hours, the majority of the energy produced is injected to the grid. This asynchrony can make solar not convenient.
Example of mismatch between solar energy production and house’s demand
New energy exchange models
To change this scenario, new energy exchange models are needed, which should encourage users to a more rational use of energy at the local level, introducing a new simple and cheap billing scheme. The natural candidate to optimize decentralized energy exchange processes is the blockchain, a decentralized technology based on distributed databases, which allows users to sign contracts and make payments with negligible marginal cost, all with a high assurance of reliability and without a central body. Blockchain technology and new business models that stimulate the local energy exchange — for example between neighbours or business entities in the same district — can facilitate the diffusion of photovoltaic plants and optimize the distribution and use of batteries, that will have a prominent role in the coming years.
A number of start-ups and big utilities are moving towards this new scenario, some with proprietary systems that are a bit in contrast with the distributed market logic, others trying to create an open platform that can integrate components from third parties. These models need also to couple with different use cases, such as micro grids, self consumption communities, condominiums and low voltage district grids.
An automated and reliable future
Additional factors that will encourage the use of smart energy management technologies at local level are the physical constraints of the power grid. Copper cables connecting residential, commercial and industrial areas could face issues in the future, causing a new wave of renovation costs for the electric grids. To prevent this regrettable future, new market models should be designed to encourage the users to use (and store) energy helping the power grid to maintain voltage and frequency within safety range. All these mechanisms will be dominated by artificial intelligence algorithms, so no effort will be required to the user, these new smart tools will work in what many already call “machine economy”.
At Hive Power we are enabling the creation of energy sharing communities where all participants are guaranteed to benefit from the participation, reaching at the same time a technical and financial optimum for the whole community.
Join Hive Power Telegram chat:
The power sector is facing a paradigm change, moving from a centralized approach with big power plants (hydro, coal, gas and nuclear) leading the energy market to a decentralized scenario adopting distributed energy resources (DER), such as solar and wind.
In this picture, a new actor is emerging: the prosumer, i.e. households or organizations which at times produce surplus energy and feed it into the local distribution network; whilst at other times (when their energy requirements outstrip their own production of it) they consume that same energy from the grid. DERs are by their nature distributed and easily accessible, so accessible that even a single residential consumer can install a small solar power plant and become a prosumer.
The transition to a prosumer-driven electrical grid can be quite bumpy¹. The lack of a centralized planning and the increase of intermittent electricity production in the lower levels of the grid raise the stress on the electrical distribution grid and can lead to severe power quality problems, while distribution system operators (DSOs) need to cope with these new issues.
Though many utilities rightly see the impending arrival of solar-plus-battery grid parity as a threat, they could also see such systems as an opportunity to add value to the grid and their business models. The important next question is how utilities might adjust their existing business models or adopt new business models — either within existing regulatory frameworks or under an evolved regulatory landscape — to tap into and maximize new sources of value that build the best electricity system of the future at lowest cost to serve customers and society.
Rocky Mountain Institute
These problems are further emphasized by the increase of electricity consumption driven by the electrification of heat generation (heat pumps) and mobility (electric vehicles), which will tend to further increase power excursions in the distribution grid.
To overcome this problem significant investments in the grid infrastructure are expected. This could initiate a so called business “death spiral”², or “grid defection”³. Prosumers reduce their regular power consumption from the central grid in favor of self-produced power. Besides they can install batteries to further increase their energy independence. Reasonably, these customers will still depend on the central grid for emergency or peak use, so electric utilities will have to operate their costly infrastructure and power-generating capabilities even as revenues from consumption decline.
We believe this bleak scenario is not the future we want. A future with a widening gap between autarkic prosumers, almost disconnected from the rest of the grid, and simple consumers forced to pay for a more expensive and inefficient grid.
On the contrary, the future electrical grid should be characterized by an increase of energy sharing between prosumers, consumers and electric utilities, optimizing the energy resource and the usage of the infrastructure. In several countries, the current unbundled situation allows the end-users to freely choose their energy supplier.
In this context, enabling technologies like blockchain, and more specifically Ethereum, will allow decentralized prosumers to safely buy and sell electricity to each other at negligible marginal costs. New aggregators exploiting this technology can act as energy suppliers and compete in the global market. In this context, distributed energy storage systems (DESS) could also participate to the energy market and thanks to their high flexibility they could quickly respond to dynamic price signals. This represents a big opportunity of cost reduction for the end user.
Today we present the Hive Power platform, a decentralized autonomous organization (DAO). The goal of Hive Power is to create energy sharing communities where all participants are guaranteed to benefit from the participation, reaching at the same time a technical and financial optimum for the whole community.
This is achieved by devising a mathematically sound market mechanism that incentives the participants to collaborate with each other, coordinating their production and consumption. In contrast to other energy sharing market schemes, the Hive Power platform takes also in account technical aspects, such as cables power rating and voltage limits in order to reach a multi objective optimal solution.
By using the Hive Power platform users are empowered to create decentralized energy communities. The scope and the size of these communities can be quite heterogeneous.
The first application of Hive Power will be the creation of self-consumption communities (SCC) on a condominium, where the members of the community consume together the produced solar electricity from their own roof by increasing their energy autarky.
Starting from this initial application, Hive Power will grow in size by including any kind of producers and consumers in the low voltage electrical grid in cooperation with DSOs.
Hive Power will also support micro-grid communities, where the connection to the main grid is not ensured continuously and the requirements of technical and financial operation are strict.
We believe Hive Power is perfectly tailored to the current grid transition, enabling a safe and cost effective operation of the electrical grid by ensuring a fair and resilient energy market for all actors involved.
We are just getting started and we are really excited for the future ahead of us.
Join Hive Power Telegram chat:
Learn more about Hive Power:
- Perez-Arriaga, C. Knittle, and M. E. Initiative, “Utility of the future: An mit energy initiative response to an industry in transition.”, http://energy.mit.edu/publication/utility-future-report, 2016.
- P. Bronski, J. Creyts, L. Guccione, M. Madrazo, J. Mandel, B. Rader, D. Seif, P. Lilienthal, J. Glassmire, J. Abromowitz, et al., “The economics of grid defection: When and where distributed solar generation plus storage competes with traditional utility service,” Rocky Mountain Institute, pp. 1-73, 2014.
- The Economist Group Limited, “A world turned upside down.” https://goo.gl/hWu16z, 2017