Practical insights to design a blockchain-based energy trading platform

Today, the development of decentralized energy management systems has accelerated due to the daily growth of renewable energy technologies and communications infrastructure. At the distribution system level, this approach has manifested itself with the emergence of the local energy market. In fact, the local energy market is becoming a new operating model to control local generation units. This paper describes the general architecture and the set of elements to be used for implementing a blockchain-based local energy market within a transactive management platform. After an overview of internet of things (IoT) communication technologies and the existing central-authority based applications, the general structure and elements of peer-to-peer (P2P) networks are reviewed. Next, the concepts of blockchain-based technologies and the required specifications for different building layers are outlined based on the very limited relevant literature available. The concepts and requirements are investigated to provide practical insights to design trading platforms.


A. Aims and Background
There is widespread growth in distributed energy resources (DERs) use. This tendency has driven more attention to have clean energy and manage the energy demand more efficiently [1]. With the advancement of technology and reducing installation costs, DER is also becoming more popular on the demand side [2]. So, both business and residential consumers are encouraged to own various DERs, including micro wind turbines (WTs), PV panels, biogenerators, and diesel. Meanwhile, electric loads are not still anymore [3]. They can adjust the power consumption perceptively by reacting to demand response (DR) signals. To this end, smart metering based on the internet of things (IoT) is needed to transmit real-time data between all users [4,5]. Hence, the entire network turns out to be a smart grid, as there is not merely a flow of energy but also a stream of data, which will be helpful to decide an efficient distribution of power over the system [6].
In a smart grid, users act as proactive consumers, referred to as prosumers in the literature. In this context, even if feedin-tariff (FiT) has been used extensively to support prosumers to take part in energy trading, unfortunately, the advantage to prosumers for engaging in FiT systems has been very marginal [7]. In fact, in this old-style manner, grid supervision is directed via a centralized management system, where a local utility accomplishes customer billing, grid balancing, network maintenance and administers regulations regarding the reward of generated renewable energy. Prosumers and consumers are stereotypically price takers and have no roles in how the price for injected power is decided. Prosumers may have challenges to pay off investment costs, and the investment dynamics of private customers in roof-top solar energy may drop below the predicted trajectory generally, in times of falling FiTs [8].
such as the demand response plans [23,24]. In fact, integrating IoT technology with the system allows real-time monitoring of both the generation and consumption sides. Also, considering the scalability need, using IoT networks to develop new and modern power systems is inevitable. Thus, smart grids, by applying IoT technology to the conventional systems routes further developments in the power sector.
A. IoT architectures So far, various frameworks have been provided for the Internet of Things [25][26][27][28]. The IoT architectures vary depending on the technology deployed or the industry used, and each one has merit in solving a different IoT heterogeneity problem. Although there are significant differences between them, they all follow a layered structure for establishing an IoT network. These frameworks connect IoT things to the web to transfer data to applications' centers, whether in the data center or the cloud, to use it. In this paper, the details of each model will not be discussed, and the sole purpose is to explain the main concepts of the building blocks. Therefore, in this subsection, a simple IoT framework of [29] has been considered for easy understanding of the concepts, which has considered the primary constituent elements in most IoT systems. This framework consists of two parallel stacks; core functional stack and data management and compute stack. Core IoT functional stack includes hardware layer and application layer. Data management and compute stack includes virtual layer elements. These building blocks include the main components of all models and are developed adaptively for different cases and applications and arranged in proper order. Fig. 1 illustrates open systems interconnection (OSI) reference framework associated with a simplified IoT architecture along with data transmission layers and transmission control protocol/internet protocol (TCP/IP) layers by inspiring form [29] and [25]. The OSI reference model is an internationally accepted model for the layered architecture of digital telecommunication networks [30]. The model defines seven layers. Each layer provides service to the layer above it. The model is applied in different ways depending on the technology, but it is not always strictly followed. Many implementations adjust the model for the sake of efficiency [30].
A clear example of this is the TCP/IP protocol stack, used worldwide. TCP/IP architecture is based on four layers instead of seven. TCP/IP includes two different protocols, TCP and IP, fitting in the transport layer and the network layer of the OSI model, respectively. Their main characteristics (scalability and flexibility), together with the great success of their use on the internet, have turned TCP/IP into the most widely accepted protocol stack [30]. Many applications have been developed over TCP/IP, and other applications have been adapted to be used over it. TCP/IP provides end-to-end connection in the IoT structure, and the network layer of IoT provides internetwork routing for data transmission [25]. According to Fig. 1, structurally, several components must collaborate to make an operational IoT network. At the Things level, physical devices must conform to environmental constraints. Usually, smart objects have to interact with an external system through a communication network. In many cases, wireless technology is used for this purpose. This part has four layers. The access network layer, which is the last point of the IoT network, typically consists of wireless technologies such as LoRa, 802.15.4g, and 802.11ah [29]. The Internet layer can be recalled as gateways and backhaul network layers as well. This layer is necessary to transmit the data to the application function. In a typical communication system, the gateway directs the collected information through backhaul to a central station where the data is processed. For successful communication, the protocols such as IP and User Datagram Protocol (UDP) must be implemented to support various devices for connection and use [29]. Also, the IoT network management layer includes additional protocols such as constraints application protocol (CoAP) and message queue telemetry transport (MQTT) to exchange data with sensors. In the model in Fig. 1, data management is coordinated with each of the three main IoT functional stack layers. The related stack may consist of three levels. Based on these levels, data management can be executed in the edge layer among sensors, in the fog layer at gateways and transmission networks, and in the cloud layer at the cloud or central data center. In the concept of edge layer, devices consume data and, by participating in the processing, produce data as well. In addition to requesting services and content from the cloud, edge devices can also perform computing tasks. Fog nodes are intermediate layers and can treat as a small-scale cloud and execute some calculations. In fact, since transferring a lot of data directly to the cloud may raise the bandwidth problem, latency problem and cause a lot of time loss, this hierarchical calculation and processing structure can efficiently manage the volume of data and can speed up the transactions.
In sum, in the context of a smart grid, the driving technologies of IoT can be clustered into three groups; (i) security and privacy-aware technologies (ii) data acquisition technologies creating contextual information from "things," (iii) data processing and management techniques [25]. Any monitoring and measurement device based on sensor technologies with communication capability is referred to as a "thing". By utilizing these things, the whole infrastructure is furnished with smart instruments that can be accessed rapidly through IoT technology. Also, these operations are sustained by providing security and privacy requirements with the aid of IoT [25]. The produced measurement information is transmitted to the monitoring and control center, where cloud computing and big data technologies can analyze and share them with the smart grids' applications.

B. Communication technologies for IoT
To manage home appliances, electric vehicles (EVs) energy sources and observe consumption of electricity, water and gas, it is desired that the state of the system becomes available on a near real-time scale. This requires appropriate communication technology. IoT technology has several merits compared to other communication technologies. It is able to provide several network structures and communications for heterogeneous and complex communication scenarios. Also, by reducing cost and power consumption, it can improve the efficiency of devices. Also, service providers need information and communications technology (ICT) to ensure service sustainability.
Therefore, mentioned features and the recent developments achieved on the internet of things have encouraged operators, service providers, and developers to utilize this technology in smart grids and other intelligent environments, such as smart cities, smart buildings, smart homes, and so on [5,26,31,32]. There are various requirements to establish these applications, including measurement, control equipment, and communication infrastructure between endpoints.
About required communication infrastructure, some regions have already invested in fiber optic cable infrastructure. In other areas, technologies, such as digital subscriber line (DSL), offer broadband data rates over existing telephone lines. As another wired communication technology, power line communication (PLC) can provide an independent communication channel to exchange data on the existing power lines.
Wireless technologies usually have lower installation cost benefits, considering the distance factor [8]. There are various wireless technologies, including ZigBee, Bluetooth low energy (BLE), narrowband IoT (NB-IoT), and long-term evolution -Machines (LTE-M). These technologies are typical for particular application plans such as Zig-Bee in home and device automation and Bluetooth in personal networks. These are commonly classified as a low power wide area network (LPWAN). Other communication technologies such as cellular and WiFi can also provide different application areas.
However, among these technologies, LPWAN offers significant advantages in terms of coverage area, range, number of station requirements, power consumption, and cost [33]. These superior features of LPWAN make it convenient for end-user IoT applications, which require low power consumption, cost, and large coverage areas. The most important LPWAN technologies are LoRa, provided by Semtech, Ultra Narrow Band (UNB) improved by SigFox, LTE-M, and NB-IoT, provided by 3GPP [33]. Among these, because of utilizing unlicensed frequency bands, the LoRa and Sigfox UNB are the broadly exploited LPWAN technologies. However, LoRa (0.3-38.4 Kbps) and UNB (100 bps) support lower data rates compared to LTE-M (200-1 Mbps) and NB-IoT (Up to 100 Kbps) [33]. Therefore, they may suffer some restrictions for use cases such as distributed applications.

C. IoT for central-authority based transactive energy applications
A smart grid based on IoT technologies, intends to provide complete information from the entire energy infrastructure. This vision empowers power plants, energy systems, and consumers to use the grid infrastructure efficiently, adapt to modern technologies, and seize the full potential advantage of systems by novel solutions. To this end, the integration process contains the entire applications from retail customers to the energy suppliers, and transmission and distribution operators [34]. These applications and services include advanced metering infrastructure (AMI), demand-side management (DSM), real-time pricing (RTP), distributed generation (DG), storage, and others [35].
By implementing a smart meter plan, communication channels can be created from the distributed measurement points in prosumer households and consumers to the data management system. However, establishing such a communication network is a challenging task. In [36], the authors introduce demand-side energy management in smart residential grids. Meanwhile, they noted that most existing studies consider perfect two-way communication, which is unrealistic for practical applications. In contrast, in [37], it is declared that the microgrid term is not a new idea, and it has already been realized in the industrial sectors in practice. The authors in [38], provide a survey of the requirements for major smart grid applications. In [39], the authors investigate the importance of communication infrastructure and its impact on the optimal operation of DGs in microgrids. They recommend using wireless technologies since they have a lower deployment cost. In [40], reliability, latency, and data rate are presented and quantified as the critical requirements of the communication network. Latency is the time delay between delivery and transmission of a message. Similarly, in [41], the authors compare a list of communication technologies and analyze their capabilities based on the quantitative needs for smart grid services.
Regular meter reading by AMI, distribution automation (DA), RTP, time-of-use (TOU), and demand response (DR) VOLUME XX, 2017 9 are applications inside the neighborhood area network (NAN) that their message size and latency can be important in the exchange of data. In [42], without overhead, regular AMI payload sizes are reported in the range of 100-200 bytes. Payload is the actual intended message within transmitted data, and other parts of data such as headers and metadata are added to enable message delivery. These values are confirmed by [43], which specify the required data rates of about 100 Kbit/s per device. For DSM, in [8,41], it is declared that data rate requirements are around 14-100 kbit/s, while RTP and TOU pricing schemes may require an additional 100 Kbit/s. As a commercial example, Fig. 2 illustrates the AMI services in the FAN ecosystem, introduced in GridBlock of Cisco. GridBlocks is one of the first Reference Models to integrate supply chain with modern communication and IoT [44]. Based on the definition, the FAN is an area of the utility IoT network that supports the connection and management of distant distribution elements, smart meters, DA, DR, workforce automation, EVs, DGs and storages, and street lighting [44].
In the context of the FAN, the smart meters form the connected grid endpoints. As mentioned, a smart meter is different from a legacy meter in that it is capable of two-way communication and typically has an IP address. So, these smart meters are IP-enabled grid devices with an embedded IPv6-based communication stack. Fig. 2 illustrates the IPenabled grid devices' communication stack for the smart meter as well [44]. In this stack, communication protocols start with short-range communication of 802.15.4, then with 6LoWPAN (IPv6 Low-power Wireless Personal Area Network), the network is connected to the global network. 6LoWPAN is a new set of standards made by the internet engineering task force (IEFT) for IPv6 over low-power embedded devices. To adapt 6LoWPAN to the traditional IPv6 network, the routing over low power lossy network (RoLL) workgroup has come up with a new protocol called routing protocol for low-power lossy networks (RPL) to optimally handle this new 6LoWPAN protocol in the main communication network [45]. Finally, the data handed over to the application layer, has different functionalities such as metering and SCADA.
The data will be gathered on the pole-mounted connected grid routers (CGRs) as an edge node for the Cisco case from a data management point of view. Then, using a suitable technology, it is transferred to the cloud and application layer. However, in general, for data management stack as illustrated before in Fig. 1, alongside edge nodes and cloud, there are possibly fog nodes as well. Some processing stages can be executed in these nodes.
Integrated Fog level in the FAN structure draws attention in the literature as well. In [45], authors utilize the IoT model structure with integrated fog intermediate for the application of the distribution automation system. The authors define an IoT based SCADA system, which is integrated with fog architecture. Their ecosystem is designed to take care of consumer utilization, outage management, power quality control, and pole transformer health.
In their model, smart meters to be installed in private homes must use the 6LoWPAN standard. Because this is an IP-based connection based on IEEE 802.15.4, each energy meter receives a unique IP address. They collect electricity, voltage, and current data from homes and send it to fog routers. IEDs mounted on pole transformers also use 6LoWPAN connectivity. These 6LoWPAN-based sensors and meters connect to a 6LoWPAN collector and use multi-hop connections to reach the Fog router. Fog routers act as a 6LoWPAN gateway, where smart meter data, line sensors, IEDs are collected in real-time for analysis and use a backbone network such as 3G / 4G to connect to the cloud. This structure is considered in [46], and based on that, the authors propose a multi-agent system (MAS) for smart energy management in a fog-based IoT system. The Agents in their IoT system negotiate with the metering agent to reduce the peak hour usage. The negotiation agent also negotiates with the metering agent for using energy when the availability of renewables is surplus. This procedure recall the initial sketch for the P2P local energy market (LEM) concept in [47]. However, the challenges and the concepts for P2P networks with a distributed environment and hardware limits must be more assessed. The next sections discuss more the P2P networks elements and performance of P2P markets in constrained condition.

III. P2P NETWORKS FOR TRANSACTIVE ENERGY TRADING
Previously, because of the lack of suitable communication and control equipment at the distribution system, small customers did not have a chance to take part in the electricity market directly. Typically, they signed a contract with retailers who participate in the wholesale market, buy energy, and supply their needs. The customers are metered individually and asked for the cost of consumed energy or paid a FiT for the injected energy. Via the P2P market, customers can trade power with each other and even the wholesale market without a retailer intermediary. However, in the new paradigms, retail suppliers can still play the old role for the customers who want to avoid market volatility [48]. Also, they can provide more services such as invoicing, real-time metering, and local energy management [49].
Furthermore, they can contribute to a LEM as a typical participant and regulate the surplus or deficiency of energy in the smart energy community and local market. Considering retailers as well as various imaginary P2P trading platforms for LEM, the architecture presented in Fig. 3 is anticipated for the modern distribution system. In this figure, each tab represents a third-party transactive management platform through a P2P network.
Each platform can be basically interpreted as a broker, and to date, its architecture has been theoretically studied by various articles. In [50], the authors suggested three layers of information, economic and physical, to build the trading platform. However, as shown in Fig. 3(a), alongside this 3layer structure, there exist other architectures, such as the 5layer model from [51] and the 7-layer model from [52].
Regulation is critical for the actual implementation of a trading platform. The legislative rules and regulatory policies are necessary to provide a framework for LEM design and its integration with other electricity markets and electrical networks [52]. The regulation and energy policy will mainly govern the success of P2P trading in the future electricity market. In fact, governmental rules decide how taxes and fees will be considered, what kind of market design will be permitted, and how the P2P market will be integrated into the existing energy market and supply systems. In sum, these decisions can imply either support or discourage connotations to the LEM. The application layer includes the required software and validity tasks that will be covered by the platform owner. This layer will be illustrated more lately.
The required P2P network, inspiring from Fig. 1, can be divided into two main layers: 1) virtual layer and 2) hardware layer.

A. Virtual layer
This layer essentially establishes a secure connection for participants to select their energy trading parameters. In fact, in this layer, the financial arrangements between buyers and sellers are accomplished. So, first, buy and sell orders are gathered. Second, a suitable market mechanism is utilized to match the orders, and finally, financial transactions are executed. To do so, the layer needs to assemble the following elements. Information system: A secured and high-performance information system is the core of the P2P power network. This system enables all participants to contact each other to participate in power trading, monitor, and control the market operation. Features that are inherent in the distributed ledger technologies propound it as a great candidate for the information system. Market application: The information system of a P2P network facilitates the market application. The objective of the application is to empower the participants to experience an efficient energy trading process by matching the sell and buy orders in near real-time scale. The following concepts can influence this element:  Market structure: In the literature, the market structures classified into three categories; Full decentralized markets, community-based markets, and hybrid markets [16]. In a fully decentralized P2P exchange, customers can negotiate with each other directly to agree on the trading parameters without any centralized administration. A community-based P2P market can be useful to a group of neighboring prosumers [53][54][55], in which the members of the community share common objectives and interests even though they are not at the same locality. A hybrid market is a mixture of community-based and fully decentralized markets in which each community and each customer can interact with each other while keeping their market assets.  Pricing mechanism: prosumers' commitment to P2P trading and the consequent benefits entirely related to the financing transactions between the participants in the trading. Therefore, appropriate pricing schemes that are mainly developed to apply to the P2P energy trading should be utilized. For example, in [56], a credit-based concept is integrated into a pricing scheme to speed up regular trading. A discernment scheme proper to be installed in a P2P network is discussed in [57]. In [48], the authors propose a distributed price-directed optimization scheme based on the different categories of prosumer classes. Also, other pricing schemes are presented in [58] and [59]. Physical layer 1

Information layer 3
Economic layer  Transactive controller: The Transactive controller (TC) of a P2P market participant secures its supply of energy while participating in trading via a specific bidding mechanism. In fact, TC is the software intermediary of transactive metering infrastructure with trading platform and may be able to decide the bidding strategy and to participate in the trading on behalf of the customer. For example, The TC of a rational prosumer may always buy energy in the microgrid market when the price per unit of energy falls below its maximum price threshold [60]. Also, at the advanced level, it can collaborate with an embedded energy management module to control the consumption pattern optimally. To handle these functionalities, TC should have access to real-time demand and supply data of the participant.

B. Hardware layer
All the trading decisions and parameters are determined at the virtual layer. However, the last task so-called settlement phase waits to a confirmation message. In fact, the buyer party should validate that the actual transfer of an agreed amount of energy is delivered over the hardware layer. The hardware layer includes a necessary framework to facilitate communication among participants and also towards the grid.
To this end, this layer contains the following elements: Physical grid: This physical network could be the traditional distributed grid operated and maintained by the distribution system operator (DSO) or an additional, separate physical microgrid distribution grid, along with the conventional network [60]. Grid connection: To exchange energy, the participants must maintain their connection points to the main grid. These points can be established through smart meters or a traditional energy meter. By using smart meters, the authorities have this possibility to examine the performance of the P2P network, for instance, in terms of cost and energy savings [60].
Transactive meter: Each customer should have the appropriate transactive infrastructure to be able to participate in P2P trading. This meter will be installed in addition to an energy meter of connection point [60]. It can be categorized as a sub-metering device which is local measuring equipment within the home network and operated independently from the traditional meter. This transactive gateway is capable of participating in the P2P energy market based on the available information about the market, including price, total demand, total generation, and network conditions [1]. It can also communicate with other prosumers in the network by any appropriate communication protocol. These elements, in addition to the trading application, may be featured with internal controls as well to be more beneficial. For instance, Fig. 4 illustrates the transactive meters utilized in designing the energy market of the Walenstadt Microgrid [8], Brooklyn Microgrid [13], and CENTS [61]. Market participants: To establish energy trading, it is necessary that there are a sufficient number of participants VOLUME XX, 2017 9 inside a P2P network, and a group of these traders should be enabled to generate energy. The policies to involve the participants are affected by the market mechanisms and pricing schemes [1]. These factors are selected and designed based on the purpose of P2P energy trading. The type of trading energy (heat or electricity) is determinant, as well [13].  [26]. With the increase in the amount of data generated from energy network applications, P2P communication architectures should be able to accommodate these increasing bandwidth applications to guarantee low transmission delays, decrease packet losses and ensure rapid peer detection and message delivery [19]. Also, a reliable communication network is essential to make sure that a message will reach the intended recipient without getting lost. Moreover, the communication technology must fulfill the security criteria to guarantee that the P2P network is solely available to approved personnel, and is robust against network attacks.

C. Challenges and technical approaches
As challenges of the virtual layer, P2P energy trading platforms should be integrated with suitable pricing schemes and mechanisms to provide the condition for the participation of an extensive number of customers. Also, the mechanisms should handle fast and frequent trading [57,59,62]. Meanwhile, all the financial transitions should be executed securely without containing a third-party manager. The main functions should be designed such that in addition to the mentioned requirements, they can provide a prosumers-centric outcome to incentivize customers to participate in the P2P trading [63,64]. At the same time, the trading pattern should support the achievement of desired aims, including peak load shaving, balancing local demand-generation, and reducing prosumers' energy costs [65][66][67][68]. Last but not least, to establish such structures, communication, and computation challenges should be identified and considered into the design processes [69,70]. The major challenges of the hardware layer mainly arise from power system limitations. As mentioned, trading parameters are settled at the virtual layer; then, the actual transferring of energy is executed via the physical grid. However, the power system puts solid constraints on the exchange of energy within its network [71]. During the decision-making process in the virtual layer, if the influences of the energy trading on the physical grid are not considered, the energy exchange might disrupt several technical constraints in the actual implementation. To avoid these complications in the aftermath of the virtual trading processes, the network studies should integrate voltage and capacity constraints to prevent overvoltage and reverse power flow issues owing to P2P trading. Also, the effect of increased use of RESs on the system strength of the power network should be examined as well [1] Considering the challenges mentioned above for the virtual and hardware layers, it can be seen that P2P energy trading is not a simple and straightforward strategy. However, to obtain feasible trading schemes that address the challenges of both hardware and virtual layer simultaneously, several technical methodologies have been approved to be used. Reviewing recent studies [1,3,72], these methods classified into the four general categories that can be the contributors to the design of P2P energy trading mechanisms: 1) game theory, 2) auction theory, 3) constrained optimization and 4) blockchain.
Game theory, by using methods of coalition formation game, canonical coalition game, generalized Nash game, noncooperative Nash game, and Stackelberg game launches the cooperation and competition among the participants of the P2P energy trading market [53,67,[73][74][75]. The obtained solution is stable, sometimes optimal, and mutually beneficial for all participants [72]. Auction is a financial resource (a) (b) (c) allocation approach that wants to balance supply and demand through a competitive bidding process [71,76,77]. Auction theory-based models, by using single-side auction models and double-side models, manage the interaction among buyers and sellers to exchange energy in the P2P trading market [72]. Constrained optimization techniques use mathematical formulation strategies such as linear programming (LP), mixed-integer linear programming (MILP), alternating direction method of multipliers (ADMM), and nonlinear programming (NLP) for optimizing the parameters of P2P trading under different hard and soft constraints imposed by the market and power system [78][79][80][81]. A smart contract, consortium blockchain, Hyperledger, and Ethereum are common methods introduced as blockchain-based techniques to create a data structure that can be shared and replicated among members to provide transparent, secure, and decentralized energy trading in a P2P network [63,82,83].

IV. BLOCKCHAIN TECHNOLOGY TO ESTABLISH P2P ENERGY
TRADING PLATFORM Implementing a local market requires an active residential community at first. In [16], the authors provide a comprehensive review of community-based and P2P markets.
Since the idea of microgrids isolated from the DSO is still incomplete and premature, a realistic approach to implement transactive energy systems should use a hybrid solution meaning that the DSO solely regulates the energy exchange and TM is only responsible for accessing and managing the information required to implement P2P energy exchanges. For instance, the DSO can control access to the information system and the smart grid. However, it does not manage energy transactions centrally. This means that: 1) peers must validate the transaction using a kind of consensus protocol embedded in the joint execution procedure, the so-called smart contract; 2) transactions must be stored securely in participating peers [3]. This is a call for the modern technology of distributed ledger technology (DLT). DLT has two types of network access named with "permissioned" and "permissionless" titles. In a permissioned architecture, access to the system must be verified, for example, by registering a customer profile in a central data center. However, no action is taken by any central system when exchanging information between peers. Skype can be considered as an example for permissioned P2P network. In contrast, a public network in which everyone can participate without any unique authentication mechanism is called permissionless architecture. All participants in this network are anonymous and untrustworthy. DLT seems to be a promising solution to enable P2P energy transactions between participants within the LEM framework, as it avoids the need for an intermediary and can transact in real-time [89,90].

A. Blockchain technology for P2P network
There are several types of DLTs available today, including Tangle, Hashgraph, Sidechain, and Blockchain [84]. The latter is the most popular DLT, where transaction groups are stored in data blocks that are chained one after the other to make data forgery almost impossible [3]. Storage of transactions' data in blocks is ensured using industry-level encryption functions and security methods, e.g., public key pattern signing [85,86]. The blockchain is stored globally among the network participants, and it is a virtuous application of the decentralization algorithm. In the blockchain world, the shared item is a kind of "value." This value can be managed by cryptocurrencies, virtual goods, smart contracts, and contracts between the untrustworthy parties. While in the centralized approach, participating parties trust the central authority, for example, a bank institution, in a P2P structure, the parties use a mechanism to gain some kind of trust. This trust must maintain at least: (i) anonymity. (ii) impossibility to withdraw a transaction after saving. (iii) the very low likelihood of forgery of the data collected; (iv) flexibility against potential attacks, such as the Byzantine invasion, in which a transaction is allowed to be stored even if it should not [3,87]. It should be noted that points (ii) and (iii) are usually secured using cryptographic hashes that define each block and chain of all blocks. In this way, forgery means the possibility of modifying the whole chain. This is not a new concept, as it became popular in 2009 when blockchain technology was used by the bitcoin platform for cryptocurrency to enable secure virtual transactions [86].
Blockchain enables decentralized P2P transactions, which is entirely in line with the idea of conducting energy transactions on the LEM context without the need for a central authority such as DSO in traditional power distribution networks [88]. Under these circumstances, blockchain-based DLT may manage up to thousands of smart contracts almost in real-time and without interruption due to data center design and maintenance [89]. However, the original blockchainbased DLT algorithm, Bitcoin, can perform up to seven trades per second [90]. Other options have been developed for this purpose, such as Ethereum [91], which can control dozens of energy transactions per second, or Hyperledger [92,93], which can manage hundreds of transactions per second. A scalable solution, which makes it very suitable for smart contracts. A comparison between Bitcoin and Ethereum is provided in [94], a comparison between Hyperledger and Ethereum can be found in [95]. Besides, in [96], the authors provide a comparison between all current DLT-based platforms used for transactive energy in microgrids.

B. Blockchain platform and consensus protocols
In a blockchain-based LEM, since there is no central unit for managing energy transactions, all participants (nodes) must agree before storing them in the blockchain. The validity of a new transaction or a block, i.e. a group of transactions is confirmed if there is a consensus between all nodes [97]. All nodes participating in a consensus produce value and the same outputs according to the protocol rules. Also, if a validator node fails, the protocol can carry on. VOLUME XX, 2017 9 Proof of work (PoW), proof of stake (PoS), and Byzantine fault tolerance (BFT) are the common consensus protocols in DLTs based on blockchain. The PoW protocol is used within public platforms such as Bitcoin and Ethereum, where a large number of anonymous and untrustworthy nodes seek consensus to approve an energy transaction [86]. Since all nodes must solve the difficult encryption puzzle (mining) before adding a block to the chain, the PoW algorithm suffers from energy footprint [98]. To modify this in the PoW protocol, the mining process is replaced by selecting a node that acts as an evaluator in the PoS protocol. According to this protocol, the right to approve and create a new block is valid for that node, which can confirm the ownership of a variable called stake. In the cryptocurrency sense, the stake can also be a currency. However, working based on stake also suffer from some problems. Nevertheless, PoS is an excellent candidate to be used in the energy framework, and by using hard-to-forge stake values and a premisssioned architecture, the inherent weaknesses of PoS can be eliminated [3]. The Byzantine fault tolerance (BFT) protocol operates based on detecting the mismatch among information shared between all nodes, thus preventing the malfunction of the entire system [99]. One type of PoS and BFT protocol is the Tendermint protocol [100], which is used in [101] to run the Quartierstrom LEM. Comparisons and descriptions of PoW, PoS, and BFT protocols are provided in [97]. Also, another review paper among all the consensus protocols based on the blockchain can be found in [102].

C. Background of blockchain-based LEM
After the Brooklyn Microgrid made the first blockchain energy transaction in Brooklyn, New York, in April 2016, the study of distribution-level energy trade using a blockchainbased approach has begun [8]. Since then, several businesses such as Power Ledger and Grid+ have begun to offer new solutions to meter, bill, and design market based on blockchain technology.
Customers in a small community in Brooklyn (USA) can buy or sell their energy to each other using smart contracts on the Ethereum platform [3]. The paper [13] summarizes the internal work-flow of the blockchain-based Brooklyn Microgrid and examines its double-auction market with a single market-clearing price. The paper divides a general architecture of a LEM into seven main components and describes each level on the Brooklyn microgrid as a case study. The Brooklyn project was developed through a blockchain-based trading platform of LO3 Energy and a microgrid management solution settled by Siemens. This platform is developed to create an energy exchange platform for prosumers, and they are planning to become an official retailer after satisfying the state regulator [103]. Also, LO3 Energy have signed memoranda of understanding with European Energy Exchange (EEX) group, to connect microgrids with embedded P2P energy trading to the European wholesale market via EPEX SPOT Company [104].
In Australia, start-up Power Ledger plans to manage a large portion of solar-powered homes that generate excess electricity locally at certain times of the day. In this project, blockchain has been used so that connected users can sell or buy their required power from their neighbourhood. The platform wants to act as an energy exchange platform for prosumers. Their first trial in Western Australia implemented with 15 residential homes, one retailor, and one DSO [103]. Fig. 5 illustrate the mechanism of the P2P exchange platform for Brooklyn Microgrid and Power Ledger trading platform [103]. As observed from Fig. 5(a), in Brooklyn microgrid, for prosumers there will be inflow and outflow of electricity. However, for the consumer, only inflow of electricity is established. Prosumers and consumers have biding on price and transaction data kept in distributed ledger on the platform. In Fig. 5(b), prosumers and consumers buy/sell electricity at fixed price on the Power Ledger platform and retailer collects transaction data and handles metering. For both sample platforms, DSO receives physical transaction information from the platform.
Another example is the British company Electron [105], which used blockchain technology to create an open-source platform for accurate measurements. In [106], the authors present a comparison among recent projects in P2P energy trading. In [9], the authors provide an overview of blockchain technology in the field of energy, which includes detailed information about the various mechanisms of consensus. In [107], the authors provide a list of research and commercial projects for microgrids using blockchain technology. However, so far, in the literature, necessary infrastructure, communication requirements, and field implementation have rarely been studied. The studies presented generally consider more conceptual introductions and applications. These works introduce blockchain-based trading schemes and LEM models to meet different goals, such as managing demand response and activating financial settlement for providers of flexibility [108], reducing participant errors by using power outage detection [109], overcoming centralized markets with a traditional pricing model [110], and conducting a continuous double auction [111].

V. TECHNICAL CHARACTERIZATION OF A BLOCKCHAIN-BASED LEM
As mentioned, in the implementation of LEM, to ensure the fair enforcement of the rules for all participants, including consumers and producers, the market application can be run with either a reliable central unit, or with a trusted subset of participants or all participants. The first case is based on the traditional implementation of the market, and its problems such as high costs of establishment, maintenance, development, and also its inflexibility in scalability have been mentioned before. It was also stated that decentralized systems could bypass these problems due to their inherent characteristics. Thus, the latter is the preferable option within the LEM context. Via blockchain technology, P2P market places can be decentralized, and this allows prosumers and consumers to trade energy inside a confined community without relying on a central authority. However, this virtual microgrid, under the condition of providing suitable infrastructures, can feature as real microgrid as well [13]. The blockchain technology is expected to have disruptive potential and revolutionize local energy markets [112]. The extensive analysis of the literature results that previous works do not provide technical details of their solutions to operate blockchain-based energy trading platforms. It is, therefore, not possible to understand the implementation details of the current blockchain-based TM infrastructures due to the lack of a detailed explanation of the software implementation. However, this subsection establishes the baseline for a reference framework for blockchain-based TM platforms that can be used by a third-party platform owner (PO) to manage LEMs.
Considering the requirements to establish P2P trading platform from Fig. 3, blockchain-based TM platforms consist of following components: 1) the application layer which is consist of the PO owned data center and user interface, where the business environment is managed; 2) virtual layer, where the market mechanism is run and the virtual trading established between the participants. This layer includes a blockchain-based information system; 3) the hardware layer, where the transactive meters realize the trading and performs all the communication to the IoT infrastructure. Fig. 6 illustrates the architecture of the Blockchain-based P2P energy market.
The first layer considers digital communication infrastructure. It can be thought of as a virtual server suite centrally managed by PO. The sole purpose of the PO is to provide software and core components of the telecommunications network for LEM participants to exchange energy data. This data can include market information, energy metering, smart contract information. It no longer performs functions such as transaction energy storage, virtual "coin" validation, etc., because all of this information is exchanged over the virtual layer using DLT, that is, through blockchain-based smart contracts. Therefore, the role of the PO is only to manage the platform. In fact, the PO act like a broker. The core components of the PO management application are 1) the servers, 2) the certified smart meters database, and 3) the analytics component [3]. This part can interacted with Web3 and be run as decentralized applications (DApps) on a decentralized peer-to-peer network as well [113]. The user interacts with the smart contract and enters its information and keeps track of essential data through the user interface and management application.

Smart contract
Market mechanism Pricing Mechanism List of transactions

FIGURE 6. Architecture of blockchain-based LEM platform
In the virtual layer, blockchain technology is implemented. All users on the market are blockchain nodes and have a copy of the transaction information as a distributed ledger. A customer bids or offers desired prices for energy exchange in the market through a smart contract. This smart contract includes all the rules and mechanisms of the energy trade VOLUME XX, 2017 9 market between the two parties. If all the rules are observed, the transaction will be done. Otherwise, the transaction will be returned, and a message indicating the failure of the transaction will be sent to the relevant party. After confirming some transactions, a new block is created and added to the chain of previous blocks. The current block header holds the hash of the last block. In this way, the entire blockchain is protected from content change and data manipulation. This layer includes all the required application program interfaces (APIs), which are essential to communicate with a smart contract.
In the hardware layer, a schematic of the physical structure of the local energy market is shown. Several smart homes are connected to the physical grid and are also connected directly to each other for energy as well as information exchange. The same power lines that are used to transfer energy from the grid to smart homes are usually used to execute transactions between smart homes. Smart homes are typically equipped with PV panels, smart appliances, energy storage systems (ESS), a transactive connection, and a standard meter. The communication infrastructure, as one of the main elements of the hardware layer, consisting of all the components needed to handle the send/ receive requests to establish the energy trading and exchange. In the following subsections, the essential concepts will be described in detail.

A. Market application
The blockchain-managed LEM empowers participants to trade local surplus energy with each other. To this end, participants usually use a user interface, which can be used to implement their sales, purchasing demands and possibly manage consumption, production, as well as market prices for each period. To enable this feature in the form of P2P network, the market app runs entirely as a consensus-based app on a blockchain platform.
Therefore, different functions and data structures are required. For instance, in [3], the MQTT is proposed as the network protocol to manage the data publishing because the authors claimed that it is a lightweight application protocol prevalent among the IoT community. Also, the authors suggest the JavaScript Object Notation (JSON) as a data format transported by the MQTT. In [114], the authors propose to use the hash and also actual values as the bid, as well as distributed double auction trade mechanism. In this subsection, the general functions and data structures of the market application are reviewed. Fig. 7 shows a sketch of the typical steps of market application and the structure of the related data collected and calculated. In the bidding phase, the market is open to gather data from participants and create order books. Market data gathering starts with the delivery of transactions from the agents. Each transaction contains a specific payload defining an order. When receiving a transaction, according to the logic defined in the blockchain structure, at first, the authenticity of the transaction signature is checked, and if it is approved, it is sent to the next step. Then the app confirms the transaction payload, controls the participant database and adds the order to its order collection if there is no problem. The information needed to place orders is extracted from the data contained in the transaction message, which includes buy price, sell price, units, and the address. This phase is defined based on the LEM clearing interval and is open between the time of the last clearing and the next time interval. However, a security margin called closing time is also included at runtime [8].
In the clearing phase, in Fig. 7, the collected orders are evaluated through the market mechanism. The output of this step produces a list of trades among the system participants in the clearing interval (X). Every clearing interval triggers the clearing process based on the application logic. The clearing of transactions essentially converts the orders collected at the bidding phase into a list of trades between participants. In this context, the more local energy available, the more transactions can be coordinated between local participants. The platform can be planned such that the grid covers the residual supply or demand. The market mechanism can be designed based on different procedures, such as game theory and auction theory, which are mentioned in the previous section.
The next pace of the market application settles matched deals into payments. In Fig. 7, the settlement phase is called every once in a while (XX), for example, once every 24 hours, to turn the transactions list accumulated during the previous settlement period into a settlement list after energy exchange confirmation, which is used more for automatic payments or billing purposes.
Clear and settlement intervals are predefined parameters of a real-time energy market, for example, in [8], they equal to 15 min and 24 h, respectively. In general, the market application, as described in Fig. 7, is a transaction-based finite state machine that is usually implemented using a web-based programming language such as JavaScript and TypeScriptbased data objects but is not necessarily limited to these techniques. So, each state can be represented by an object in which the data related to collected buy and sell orders, matched trades, and settlements as well as participant account information. Besides, the market application should be compatible with the platform specifications in the blockchainmanaged LEMs. For example, in [113] and [114], smart contracts are utilized, and thus, the implementation of the bidding, matching, and settlement processes, must be agreed upon by the participants in the sense of community consensus.

B. Market participants
The blockchain-based LEM is made up of different types of participants: the base of the platform is built by its validator nodes, which can usually be represented by specific participants. For example, in [101], the prosumers and the utility company are selected as validators. There are also peers called consumer nodes who cannot offer new blocks but execute transactions by directing their communications to the blockchain over validators . . .

FIGURE 7. Typical phases of the market in the blockchain-based LEM
Each LEM participant uses a transactive meter, which is a hardware component that is typically a single-board computer (SBC) and is mounted on the building's input meter panel. Depending on the role of the participant in the system, the SBC runs software that is referred to as TC in the previous section. For example, in [8], devices installed on PV systems run the blockchain platform and the LEM program in addition to the agent software, given their validation role in the utilized Tendermint blockchain. A software agent runs on each device to obtain user measurements and preferred order settings. Each participant can communicate outdoor and transmit energy data in almost real-time, for example, reporting energy costs of the building and energy production. This information is essential for the overall performance of the architecture.
In [3], a superordinate structure is proposed for the transactive meter in the form of a home energy management system (HEMS), which can manage and control the smart home. The purpose of the HEMS is to let the user access the TM platform to act as a transactive agent within the LEM, which is considered in the study of [71] as well. Fig. 8 illustrates a typical HEMS structure.
As observed, HEMS consists of three main components: a TC, a home device gateway (HDG), and an energy management system (EMS). HDG is an interface for communicating with smart devices in the home. In fact, HDG allows HEMS to access the user's smart devices. With this access, sensors and actuators such as switches, dimmers, etc. can send measurements and receive control commands from the EMS. In the HEMS structure, the transactive controller is VOLUME XX, 2017 9

FIGURE 8. A typical Structure of HEMS
connected to EMS, HDG and electricity meters. As mentioned before, it is a software engine needed to analyze and decide on energy trading operations. For example, a TC can make offers to buy or sell energy and receive LEM information.
As a typical operating routine of a home to participate in LEM, PV panels send energy generation information, ESSs send status information, and smart devices send energy consumption information to HEMS. The EMS processes this data to detect the current energy status of the smart home. According to this analysis, one of the three situations of equilibrium, energy shortage, or energy surplus can occur for a smart home. Depending on the current energy situation of the smart home, its owner can act as either a power plant or an energy consumer, after deciding and selecting the parameters of the transaction whether manually or automatically, the status information of a smart home is sent from the transactive controller to the virtual layer to participate in the trading.

C. Throughput rates and latency
In the blockchain-based LEM, the communication layer, consisting of all the components needed to handle the requests. As mentioned in the previous section, various requirements should be considered to select the proper communication technology. Data rate in Kbit/s and latency in second (s) are two of the fundamental factors. As blockchain systems are based on transactions which alter the state (the execution order and results of trades) of the system, the throughput as another feature is measured in successful transactions per second (tps). Despite the importance of this issue, few cases in the academic literature have discussed the requirements of decentralized architectures for AMI applications in the energy sector.
The main limitations of LEMs based on the distributed architecture are usually due to the low computational power of SBC-based transactive meters and the limited bandwidth of the underlying communication networks [8]. As mentioned earlier, blockchain-based systems require higher bandwidth to work due to the synchronization processes between distributed nodes. This need to feature the transaction throughput rates as another consequent requirement of feasible blockchain platforms. The throughput rate depends on several parameters, such as the number of validators, the consensus algorithm used, the hardware used, and so on. But, because blockchain technology is new, there is little information about the throughput rates in the limited environments for applications such as LEM.
For market applications, the bidding phase of the LEM is executed by incoming transactions to the blockchain platform. Meanwhile, clearing and settlement as other phases of LEM are time-triggered processes that are called by a validator. These processes are not based on transactions, but still, change the state of the system. As mentioned, during the specified intervals, these processes are regularly executed. During each interval, the bidding stage should evaluate a transaction for the individual participant in time. This makes it the process that requires the most intensive communication in the market application [8,114]. Hence, the speed limits and maximum transaction throughput of the bidding phase should be mostly considered to select a suitable communication technology. Generally, the communication limitation originated from two reasons; hardware device due to its computational capabilities and communication infrastructure [8].
Hardware limits usually rarely applied appropriately in the existing literature. In [115,116], maximum throughputs are tested with some benchmarks. Blockbench introduced in [115], is an assessment framework for analyzing private blockchains. It is designed to incorporate a private blockchain and measure its associated fault-tolerance, scalability, latency, and throughput. In the paper, various tests on Hyperledger, Ethereum, and Parity blockchains are presented, and their performance on a sample system is examined. In [125], the authors study the scalability of a blockchain-based local energy market. To do this, they use a private Ethereum blockchain. The authors examine the conditions required to process a day-ahead market and the energy market in realtime. In work, the transaction throughput is analyzed in terms of different trading cycles and the number of participants. The studies mentioned above provide useful information about the throughput in the blockchain. However, they study throughput not based on limited hardware but based on high-performance cloud computing nodes.
In [8], considering Raspberry Pi SBC as the transactive meter, two types of experiments are performed to evaluate the throughput rate over the Tendermint blockchain-based LEM and Raspberry Pi SBC. First, they compare a simple value transfer application (referred to as Cointest) versus the market application to examine the effects of constrained hardware. The market application is more complex since it should further examine the validity of the transaction payload, affiliates participants for assign shares and adds the acceptable offers to the order list. They reported:  the maximum average transaction throughput for data rate within 50 to 16,000 Kbit/s, are 62 tps at 750 Kbit/s for This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2021.3127890, IEEE Access VOLUME XX, 2017 9 Cointest application and 10.5 tps at 200 Kbit/s for market application.  Since hardware is saturated after reaching these points, despite the increases in data rate, the throughput values are almost indifferent to these changes. In the next step, to gain insight into the execution of multivalidation situations for P2P trading, the authors set up another test in [8] to evaluate the throughput and the bandwidth with a different number of validators. To this end, they consider the LEM with validator systems of low (1-8 validators), medium (12-40 validators), and high (48-64 validators) degrees of decentralization. They reported:  Degrees of decentralization over eight validators cannot establish a feasible network operation below data rates of 250 Kbit/s.
 A minimum requirement of 250 Kbit/s indicates that constrained communication infrastructures, such as Lora and NB-IoT, can only provide stable and acceptable performance for low-decentralized market applications.  With the increase in the number of validators, due to the increased coordination between them, the throughput will decrease and will cause more demand for network communications as well as computing overhead. For example, for a 32-validator configuration, the system requires at least 2000 Kbit/s to process more than 1 tps.  For high degrees of decentralization, data rate change cannot affect the transaction throughput considerably, due to that the coordination between validators is computationally so intensive for the Raspberry Pi SBC. Besides, another test is provided to check for the latency of the system. Smart grid applications, such as DER and DA controllers, require latencies of less than 300 milliseconds to 2 seconds [41]. However, in the case of a LEM, these limits are within the range of 5-60 s [8]. They reported that the latency varies from 9.8 s to 1.2 for low, 6.9 s to 120.6 s for medium and over 100 s for high degrees of decentralization. This result reinforces the hypothesis that the consensus process is computationally too cumbersome for SBCs at high degrees of decentralization.
In [117], the authors assert to evaluate blockchains for the IoT applications but have used three high-performance computers, without applying any limiting over the computational performance. In [118], the authors analyse Tendermint consensus mechanisms based on highperformance Amazon EC2. Considering their investigations, it seems that using Cloud-based blockchain may resolve the communication infrastructure barriers. However, the cost of implementing nodes on the cloud can be a negative factor in this matter.
Briefly, as observed, although a high degree of decentralization can increase system resiliency, it can raise latency, as mentioned above. Higher latency means that it takes a longer time for a transaction to be processed and insert in a block. This reduces transaction throughput. So it is required that a suitable communication infrastructure designed and implemented considering the base structure of LEM. The next solution to get rid of the physical limitations of communication is to use cloud capabilities. Blockchain templates have even recently been activated for some cloud service companies. In addition to this solution, implementing the transactions in the form of an off-chain application can also be a practical and up-to-date solution that can be considered in future works for the blockchain side.

VI. CONCLUSION
As an emerging and applied technology, blockchain has attracted the attention of academia, the utility industry and related service providers. This new technology has allowed adopters to explore new applications and concepts that are believed to enable innovative business solutions. Peer-to-peer (P2P) energy trading is one of these solutions. By using these systems, prosumers can get higher rewards for their electricity generation, and consumers can use local and generally clean electricity generation and reduce dependence on the centralized grid.
Considering these benefits, several articles have used the conceptual, theoretical foundations, and profit and risk analysis of blockchain technology to design their applications. Also, a few pilot projects have been accomplished in recent years, focusing on P2P energy trading platforms. However, most of them were not executed in an academic setting. Thus, projects usually did not lead to subsequent academic publications with insights beyond conceptual studies, simulations, and requirements engineering. Therefore, most of the available literature is theoretical and does not cover practical perspectives. However, this paper attempted to provide an appropriate and realistic framework for the transactive management platform by combining general concepts and few outcomes available from practical projects. To this end, requirements on the communication infrastructure, guidelines, and results were gathered and summarised from relevant literature. Also, in this paper, the IoT architecture for P2P transactive energy applications and technical characteristics of a blockchain-based local energy market were provided.
From a future perspective, Hardware-In-Loop-based simulations and a pilot project are considered to be accomplished in the next level of the CENTS project plan.