A blockchain-based IoT data marketplace

Radhakrishnan and Krishnamachari [23] provided some seminal work on applying blockchains to data marketplaces, however, with a focus on the actual payment for data. For this, the authors describe a (SDPP) to realize a micropayment system for (IoT) data streams. The protocol is based on distributed ledger technology, and the reference implementation uses IOTA both as a cryptocurrency and distributed ledger. The protocol consists of three different components, including a data channel, a payment channel, and a record medium. The buyer initiates the connection with a hello message, to which the seller is going to reply with a menu that consists of the offers. The buyer can now make an order. After that, the buyer uses the public key of the seller to exchange a symmetric encryption key, which is used for further communication. Consequently, the data flow starts, and the buyer pays the seller based on the granularity defined in the menu. Every order, invoice, and payment is recorded on the distributed ledger.

(SPS) is a protocol proposed by Zhao et al. [24] to enable reliable data distribution in the environment of (CPS). The architecture differs from traditional pub-sub solutions in that middleware is not required due to the use of blockchain technology. The authors create blockchain-based fair payments with the additional use of a reputation system. Within the (SPS) model, data providers advertise on the blockchain which topics they offer. Data consumers announce their interest in certain topics and make a deposit. The provider uses the blockchain system as a communication medium, whereby the data to be transmitted is stored in encrypted form on the blockchain. Afterward, the stored data can be retrieved and decrypted by the consumer. The reputation system ensures that only publishers with a reputation score over a specific threshold can publish a transaction. While the model ensures confidentiality, verifiability, anonymity, no trust, fairness, and reputation, the throughput and storage space of Bitcoin or Ethereum can become a significant problem since the data is stored on-chain.

In [25], the authors propose a protocol that enables fair data trading based on Bitcoin transactions. The authors make use of private key-locked transactions by providing a new Bitcoin opcode and exploiting an (ECDSA) vulnerability. The protocol can be divided into three different phases: the data correctness proof, the signature commitment, and the private key exchange. Beginning with the data correctness proof, the buyer receives encrypted chunks of the requested data. The data must ensure a condition that the buyer stated in the request. Based on a cut and choose protocol, the buyer selects a random subset from which the seller has to provide a correctness proof based on the condition. With this evidence, the buyer can be sure that the data is correct with a certain probability. Subsequently, the signature commitment phase can be carried out. The buyer requests a signature from the seller, including a specific nonce. The seller generates a signature using its secret key and the received nonce and transmits it to the buyer, which can verify the signature by using the public key of the seller. In the last part of the protocol, the buyer broadcasts a private key-locked transaction, including the payment for the data. After that, the seller can receive the funds by providing a signature with the same nonce as in the preceding phase, which is then used by the buyer to restore the private key and decrypt the data.

The previously discussed protocols take advantage of the blockchain, but their focus is on the actual payment process rather than providing a full-fledged data marketplace. Consequently, we will also look at different solutions for decentralized data marketplaces, which may use similar protocols to implement data trading.

A provider, consumer, or broker needs to be registered to become part of the data marketplace [6, 31]. Since we are using a smart contract platform, respectively blockchain technology, to implement the data marketplace, each participant of the data marketplace must have an account for the chosen smart contract platform. The marketplace may also need more information (e.g., personal information) about the participant, which also requires a user profile.

Further, providers must be able to manage their devices that are the actual sources of the data to be traded on the data marketplace. Each provider can have multiple devices through which it generates different data. With this, the provider can then proceed to create various products, i.e., data streams offered by the registered devices. The distinction between products and devices makes sense with the assumption that devices can offer several different products, and not every consumer is interested in the whole batch of information generated by a single device. In addition, consumers get more detailed information about the device generating the data, as this can be added by the provider when the device is created. It also allows consumers to search for products generated by a particular device.

Product management enables providers to take care of their products offered on the data marketplace. A provider can create several products which can be bought by consumers, whereby every product is generated by a specific device. Also, a provider might want to update the interval, i.e., the frequency in which new data is generated because the mode of operation of the device has changed, or to adjust the price to respond to market fluctuations. If the provider is no longer willing to continue to offer the product or the device is no longer operated, it should be possible to delete the product from the data marketplace. The removal of products that are no longer offered reduces unnecessary interactions for potential consumers, which have to deal with outdated information.

While most existing data marketplaces focus on fixed pricing models, e.g. [23, 27], we also want to facilitate price negotiations between data producers and consumers. The opportunity to negotiate with each other makes it possible for the participants to represent their interests and thus identify better deals between the negotiating parties. For this, the buyer and seller should be able to directly communicate and engage in a negotiation process to agree on an offer.

A trade is concluded with the settlement. Both parties have to agree on the payment and the conditions of the trade. The seller would like to charge the buyer for the transferred data, and the buyer must be able to pay the seller. Additionally, the protection of the participants engaging in a data trade is an important issue that needs to be considered. The participants may fail to abide by the conditions of the trade, be it intentional or unintentional false behavior.

Another essential part of a data marketplace is how the data is routed and transmitted. The buyer must be able to receive the purchased product. In the literature, there are different approaches on how to realize the communication between buyers and sellers. Some solutions rely on direct communication between the participants, e.g. [5], while others, e.g. [27], rely on brokers to forward the data to the buyer. Without a reasonable exchange of data, no trade between contractors can be handled.

A rating or reputation system is extremely common in today’s data marketplaces [5, 27, 30]. It enables participants of the data marketplace to assess the reliability of other participants and the quality of the offered products. Further, it encourages honest behavior since participants want to keep their rating as high as possible to be appealing to potential trading partners. Participants with a good rating may be very hesitant to interact with others that have a bad rating.

Monitoring provides a data marketplace with the ability to track certain metrics, which can be used to compare and rate its participants and products. The most frequent metric tracked by current solutions of data marketplaces is the number of data transfers between users [5]. The monitoring ability lays out the basis for the protection of providers and consumers since it can be determined whether both parties agree on the quality of the trade by comparing the recorded metrics, and if this is not the case, a dispute can be lodged.

The discovery and selection of products is an important part for every consumer. Consumers need to find the right products that satisfy their needs and select them for purchase. Consumers should be able to query the data marketplace, which then matches the products to the query and returns the positive matches to the consumer. Therefore, every product should provide the necessary metadata to facilitate this process. This metadata provides more precise information about the product, enabling a targeted search to satisfy the customer’s needs.

Finally, the participants shall also be able to interact with the data marketplace through user-friendly interfaces. While there are many data marketplaces, many of them neglect the necessity of a user-friendly interface to make the data marketplace applicable. It provides users with the ability to browse the data marketplace and make use of its different features. For example, [6] provide access to the data marketplace through the usage of WS-* or (REST) Web services, which enable the registration of devices and consumers.

Summing up the discussion, we identify the following functional requirements:

A proxy enables providers and consumers to integrate their (IoT) devices with very few computational resources in the decentralized (IoT) data marketplace. A provider respectively consumer can operate one or more proxies, depending on how far its (IoT) devices are distributed. This possibility ensures that (IoT) devices that are geographically not close enough to each other do not need to use the same proxy, which would result in inefficient communication. The most important task of a proxy is to represent the underlying (IoT) devices in all matters viable, so they have to fulfill as few resource-intensive tasks as possible. (IoT) devices usually have quite limited computational or energy resources [38]. This lack of resources makes it very difficult to implement various functionalities necessary for participation in the data marketplace.

(IoT) devices would have to carry out a high number of cryptographic operations. Providers and consumers need to encrypt the data to ensure privacy, confidentiality, and integrity of the data. It is particularly problematic if the (IoT) devices need to maintain multiple encrypted connections simultaneously, whereby multiple connections alone are already stressful enough. Further, some interactions with the smart contract platform require the (IoT) device to sign a transaction.

If the (IoT) devices have enough resources, it would also be possible to communicate directly with the brokers and the smart contract platform, i.e., no proxies are necessary. However, a proxy also brings benefits in terms of security. Instead of allowing direct access to the (IoT) devices, the proxy facilitates increased security by hiding the infrastructure behind the proxy. Therefore, it is not possible to access the (IoT) devices directly from outside the network.

A broker facilitates the data trading process and is responsible for highly resource-intensive tasks. Further, brokers act as mediators between producers and consumers if they have a dispute during a trade. Brokers have all the details about the traffic and, therefore, can resolve a dispute.

The device on which a broker is operated should have enough computational resources. An incentive mechanism ensures that a broker is rewarded for providing its resources since more computing power also means higher costs. Therefore, not only the provider is paid for the sale of its data but also the broker who has made its computing power available. This reward gives owners of hardware infrastructures an incentive to run a broker.

Since a proxy is operated directly by the provider or consumer, it is also advantageous to relocate the heaviest and most resource-intensive tasks to a broker. These tasks include the management of numerous concurrent connections and product discovery. The more participants the data marketplace has, the more connections have to be managed by (IoT) devices or the proxy, whereby the number of connections can become very high. A broker acts as a middleman between providers and consumers and forwards the messages to the right consumer. A broker also prevents message loss if a consumer is offline or can not receive the messages.

Also, the discovery of products listed on the decentralized (IoT) data marketplace is particularly complex, as the number of them can become very large. Consumers need to find products that meet their requirements. Checking these criteria must be done for each product listed on the data marketplace, which makes it a very resource-intensive task and is therefore also taken over by the broker.

Monitoring the data transfer is also an important responsibility of a broker. The recorded metrics enable a broker to determine if the provider or consumer behaves honestly. A broker knows both what data the provider has sent and which data the consumer has received. This assessment works only as long as at least two parties behave honestly. This approach is not enough to ensure fairness if a provider or a consumer cooperates with a broker to cheat the other party. However, brokers are encouraged to behave honestly to maintain their reputation.

The (IoT) device is a context-aware device that can store and process data, communicate with other entities over standardized protocols, and is uniquely addressable. (IoT) devices can be smart devices, sensors, or similar objects, which among other things, can record various physical or chemical properties of their surroundings.

However, these devices mostly do not have a lot of computational or energy resources and storage capacity, which has to be considered in the design of a blockchain-based (IoT) data marketplace. Therefore, as pointed out above, the (IoT) devices “offload” certain functionalities to brokers and proxies. The (IoT) devices use a proxy to use the functionalities of the data marketplace and communicate through the proxy to invoke functions of smart contracts or transmit or receive data from a broker to buy or sell products on the data marketplace.

The users of the data marketplace can interact with the (DApp) through a user-friendly interface. The (DApp) UI furnishes the possibility to use the various functionalities provided by the smart contracts of the data marketplace. Through the (DApp) UI, users register themselves to be able to participate in the data marketplace. Furthermore, the (DApp) UI offers users the possibility to browse the data marketplace and view the different users, devices, and products. Further, users can interact with the (DApp) UI to manage their profiles and devices. The proxy has an additional (GUI), which allows a user to configure the different wallets for their (IoT) devices.

The decentralized (IoT) data marketplace uses different smart contracts deployed on a smart contract and decentralized application platform to realize specific functionalities and enforce the rules of the data marketplace.

To participate in the system, users have to register themselves and provide personal information for their user profile. The user profile enables the possibility to get the contact details of other users and the necessary information to generate invoices. The user contract is responsible for managing the user profiles storage and keeps the personal information about individuals, small organizations, and large companies on the data marketplace. This smart contract provides the means to create new user profiles, and it gives users the ability to update their profiles to keep their personal information up-to-date. Additionally, this contract makes it possible to retrieve the profile of specific users. If a user no longer wishes to use the system, existing profiles can also be deleted. Since blockchains do not support the deletion of data, we will take a closer look at this process later (see Sect. 6.1).

The data trading process is also realized through the usage of smart contracts. The negotiation contract provides the participants with the possibility to start negotiations with each other. It is responsible for managing the bidding contracts whereby a bidding contract enables providers and consumers to exchange bids and creates a transparent view of the negotiation process. Both parties can see how an agreement or no agreement was reached. Furthermore, the trading contract is responsible for managing all trades. Each trade is assigned a settlement contract, which acts as a conditional escrow and facilitates the settlement process. Further information on the implemented smart contracts is provided in Sect. 6.1.

Initially, a user creates a profile on the data marketplace. Managing the user information requires only very few interactions with the user contract. The (GUI) provides the user with the possibility to send transactions to the user contract to invoke the create, find, update and delete operations offered by the smart contract. For this purpose, the user must have an account on the smart contract and decentralized application platform, which can be used by the (GUI) to interact with the smart contract. Further, the user contract ensures that users can only manage their profile that is associated with their private key. The deletion does not completely remove the data but rather only removes it from the current state of the smart contract as it stays part of the blockchain’s history.

Once a user has created a profile, it is possible to use all functionalities of the device contract. The device contract offers the functionalities to create, read, update and delete devices. For this, too, only a transaction has to be sent to the smart contract, as is made possible by the (GUI). Further, devices must also be registered on the proxy since the proxy must be able to authenticate the various devices to send transactions to the smart contract platform on their behalf. The proxy manages a separate key pair for each device, which can only be used if the device is successfully authenticated. If a device can carry out the necessary operations itself and has direct access to the smart contract platform, the detour via the proxy does not have to take place.

Each user that wants to sell data can use the product contract to list new data products on the blockchain-based (IoT) data marketplace. The created products can also be updated, deleted, and searched, and the smart contract ensures that a user can only manage its products. To use these product management functionalities of the data marketplace, users also only have to send a corresponding transaction to the smart contract platform, which then carries out the respective operation.

The discovery of products (see Fig. 4) is a very resource-intensive task facilitated by a broker since the broker is usually operated on a highly resourced device. To search for a product, the consumer sends a search query to the proxy, which is responsible for forwarding this request to a broker. Since several brokers can be considered, the consumer can also use the proxy to search for a suitable broker. The consumer can decide which broker is most suitable based on several criteria, e.g., the geographical location of the broker to reduce latency. The search process for a broker is the same as for a product, only that it is carried out directly by the proxy.

After the broker has received the search query of a proxy, it uses the product contract to iterate over all products listed on the data marketplace. Here, the broker examines each product according to the desired properties specified in the query. After the broker has checked whether the product satisfies the query, it sends the product back in response to the proxy, which forwards the result to the consumer. The consumer can use this result to select a product that meets his previously defined properties.

The negotiation process is always initiated by the consumer who wishes to buy a particular product. For this purpose, the consumer sends a transaction to the negotiation contract to request a negotiation with the provider of the product. The smart contract ensures that only the provider of the product can respond to the request, which can either accept or reject the request. If the provider accepts the request, a new bidding contract will be created.

After the creation of the bidding contract, both parties will be able to use this contract to negotiate the terms of the trade. The consumer uses the smart contract to submit the first bid. The provider is informed about the bid and has two ways to respond. Should the provider be satisfied with the bid, it can accept the offer directly. If there is any further need for negotiation, the provider can submit a counter-bid, via which the consumer will also be informed. The consumer now has the same options as the provider to respond to the counter-bid. Either the consumer accepts the counter-bid or creates a new counter-bid. This process can be repeated until the two parties have agreed on the terms of the data trade. As soon as an offer is accepted, the provider takes over the creation of the trade through the trading contract. Here, all conditions of the trade are determined and who is involved in it. Creating the trade also generates a new settlement contract which is used for the settlement of the trade (see Sect. 5.2.5). After the creation of the trade, both provider and consumer are notified so that they can continue with the data trading process.

If the consumer wants to buy the product directly, no negotiation is necessary. In this case, the trading contract offers the possibility to create a trading request for a specific product, which can be accepted or declined by the provider. If the provider accepts the request, a trade will be created with the price specified in the product contract. The advantage here is that no additional fees arise from a negotiation.

After the consumer has paid for the product, the provider receives a notification, and the data transfer can start. To encrypt the data, the provider needs to get the consumer’s public key from the device contract. After that, the provider sends the data and the key to the proxy. The data is encrypted with the key and sent to the responsible broker. After the broker has confirmed that it has received the data, the provider increments its counter that records the number of transmitted data packets. The broker also manages a counter, which indicates how much data has been received. After paying for the product, the consumer starts to pull the data from the broker. The data is also routed through the proxy, which decrypts the data and sends it to the consumer. After receiving the data, the consumer also increases its counter. This process is repeated until the trade expires, which is determined at the time of purchase. If the consumer desires an extension, it must renegotiate with the provider.

The settlement process is started before the data is exchanged. The process starts with the payment of the product by the consumer. The reason for this is to protect the provider from sending the data to a consumer who can not pay for the product. On the other hand, the consumer is also protected against malicious providers since the settlement contract acts as a conditional escrow, which ensures that the funds are only transferred if certain conditions are met. After the data transmission, the provider and consumer send a transaction to the settlement contract to settle the trade by disclosing their counters. These counters are used by the settlement contract as a basis for deciding if a dispute should be lodged after receiving the last counter. If the counters match, the funds are transferred to the involved parties. Otherwise, the broker will be informed of a dispute, which will then react to it by sending a transaction with its counter to the settlement contract, which will dissolve the dispute and then transfer the money.

The data marketplace uses a rating system to reward honesty and penalize misbehaving participants. The rating process is initiated by a settlement contract which calls the rating contract. Hereby, the rating contract ensures that a settlement contract can only rate the participants involved in the corresponding trade. After the contract has ensured that the settlement contract is authorized to carry out a rating, it asks the device contract for the current rating of the provider or consumer. The rating is calculated and then set by using the device contract.

The main task of the user, device, broker, and product contract is to provide (CRUD) operations for the respective entities that are to be saved via the smart contracts. But also, the negotiation and trading contract must at least provide create and read operations. Solidity provides two data structures for storing collections. The first option would be to save the data in an array of fixed or dynamic lengths. However, the data can only be accessed through the index, which is sometimes not sufficient. The other option would be to save the data in a mapping, which enables random access through a key.

A mapping offers the opportunity to efficiently read specific entries from the smart contract, which is essential functionality for the data marketplace. However, this advantage also comes with the disadvantage that Solidity does not offer the possibility to iterate over the keys and entries of mappings, and there is no possibility to determine the number of entries in a mapping. To compensate for this, we store an index for the mapping, which is a dynamic array that stores all keys of the mapping separately. The number of entries in the array can be easily determined, and thus also the number of entries in the mapping. It is also possible to iterate over arrays, which indirectly makes it possible to iterate over the mapping since the keys of the mapping that are stored in the array can be used to directly access the entries of the mapping. The combination of a mapping and an array, therefore, offers the basic requirements for managing the data.

Creating a new user, device, broker, or any other entity that needs to be persisted through a smart contract requires the smart contract only to store the entity in the mapping with its ID as the key and add the key to the index. Furthermore, the necessary references to other entities have to be set by calling the corresponding function of the smart contract, which manages the other entity. For example, when creating a device, the ID of the device must be added to the user, which is saved via the user contract. Smart contracts provide the necessary functions to set these relationships between entities. When updating an entity, the smart contract first performs a look-up with the key and then updates the entity. With findById, findByIndex, and count functions, a smart contract provides the necessary interface to retrieve specific entries or iterate over all entries stored in the mapping of the smart contract. To iterate over all entries, the caller gets the size of the index array and retrieves each entry one by one by providing the index. Deleting entries is only possible for users, brokers, devices, and products, whereby only a soft delete is performed by setting a deleted flag. Furthermore, delete operations are cascaded, e.g., deleting a user means that the relevant brokers, devices, and products are also deleted.

Authentication and authorization is an important factor that was taken into account when implementing the smart contracts, as these are public and accessible to everyone. Therefore, for all functions of the smart contracts that change the state, the sender’s address is first used to check whether the account is authorized to carry out this action, or it is ensured directly via the code that an account can only manage its data. It was also necessary to consider how the smart contracts are linked to each other dynamically and during deployment. The addresses of settlement contracts, for example, must also be saved in the rating contract so that it can ensure that only these contracts can change the rating. It is not possible to replace the implementations of the smart contracts after the deployment because the addresses can only be set once in the corresponding contracts. This has the advantage that no central authority can swap the implementation in its favor after the deployment, but it is also not possible to carry out an update.

In Sect. 5, we have already discussed smart contract-based data trading. Now it is time to take a closer look at the implementation of the individual components which are necessary for this.

The negotiation contract stores all negotiation requests and negotiations. To request a negotiation, the consumer only needs to call the smart contract’s request negotiation function, specifying the ID of the desired data product. In contrast, the provider can use the accept negotiation function of the smart contract to start the negotiation process. When the function is called, a negotiation is saved on the blockchain, and a new bidding contract is deployed. The negotiation object specifies the consumer, the bidding contract, and the subject of the negotiation, i.e., the product.

After that, the consumer can proceed with creating a bid through the previously deployed bidding contract and call the make bid function stating the bid, which includes the price as well as the start and end time of the data stream. The same is also possible for the provider, so that offers can be exchanged. It further provides functions to accept and cancel the bidding process, which ensures that no new actions are possible apart from retrieving data from the smart contract. The smart contract regulates that both parties can only alternately call functions of the smart contract. The last saved bid of a bidding contract in which the accept function was called thus represents the offer that has been agreed upon.

Purchase without negotiation takes place directly via the trading contract by calling the request trading function, whereby the consumer specifies which product it wants to buy, the broker that facilitates the trade, and the start and end time of the data stream. The request is then stored on the blockchain, whereby the consumer automatically accepts the specified price by the provider.

Subsequently, the provider has two options to create a trade. For this, it can either call the accept trading request function or create function of the trading contract. In the first variant, the provider must specify the trading request which should be accepted, whereby the trading request stores the conditions of the trade. In the second variant, the provider specifies the negotiation and the broker, whereby the conditions agreed on in the bidding contract are used for the trade. In both cases, the smart contract enforces that a trade can only be created with the conditions that both partners have agreed on. When a trade is created, it is saved in the trading contract and stores the conditions of the trade and the address of the settlement contract.

The settlement contract provides the consumer with a deposit function to send Ether to the contract and ensures that a correspondingly high amount is paid to cover the costs of the trade. Then, both provider and consumer can start exchanging data. After the transfer has been completed, both provider and consumer call the settle trade function of the contract and provide their counters (see Sect. 5.2.4). When the function is first called, only the caller’s counter is saved, and the second call compares the two counters and continues with the settlement. If both counters match, the counter is used to calculate how much money is paid out to the provider, broker, and consumer. Then, the funds are transferred to the corresponding parties, and the trade is considered settled.

However, since some problems can arise, such as that the provider and consumer disagree or do not continue the process, certain exceptions must be considered. If the counters do not match, a dispute is created, which the broker must resolve. For this, the smart contract offers the settle dispute function, which can only be used by the broker after a dispute has occurred, whereby the broker determines the value of the counter. Since it cannot be ruled out that one of the two parties does not call the settle trade function, a resolve timeout function has been added to the settlement contract. If one of the parties does not call the settle trade function up to a certain point in time (e.g., 24 hours after the actual end of the trade), the party that behaved as expected can withdraw the funds from the contract. If the settle trade function is not called from either party, the funds are sent back to the consumer.

At the end of the settlement process, the settlement contract calls the rating contract to evaluate the involved parties. The rating process is kept very simple since the focus is more on ensuring that only the settlement contract is authorized to rate a user, as has already been discussed in Sect. 6.1.2. Nevertheless, the contract provides two functions for the settlement contract to rate the involved parties of a trade. One calculates and sets the rating in the case of a successful settlement and the other one if a dispute occurred. In the first case, the user’s rating increases, whereby in the second case, it decreases. A user’s rating is represented by a numerical value between zero and 100, with 100 being the best and zero the worst. In future work, more complex calculations of the rating could be considered, but currently, Solidity does not support fixed-point numbers, which makes complex calculations difficult.

The proxy implements multiple (gRPC) services. These services include one service for each smart contract, which enables communication with the smart contracts deployed on the blockchain using a proxy account with its corresponding wallet. The accounts with their wallets can be managed by an administrator through the account service and the wallet service. Furthermore, the proxy provides a discovery service through which brokers and products can be searched. An authentication service enables the users of the proxy to authenticate themselves, and a message service is responsible for the encrypted transmission of the traded data.

The data of the accounts and wallets are stored in an SQLite database. An account consists of a username, password, and role (admin or user), whereby bcrypt is used to only store the hash value of the password in the database. A wallet can be added to each account, with one wallet consisting of the Ethereum address, public key, passphrase, and the path to the key file. The key files are stored in a separate folder on disk, whereby every file is encrypted with the passphrase specified for the wallet.

After accounts have been created for the users, they can authenticate themselves using their username and password and receive a (JWT) in exchange. In addition to the standard claims, the user ID and the role of the user are also encoded in the token. All services except the authentication service require that a valid (JWT) is present in the authorization header of every request.

Calling smart contracts with the help of contract services works for every smart contract according to the same principle (see Fig. 5). The provider or consumer issues a unary call to the corresponding contract service with the (JWT) included in the header. The proxy selects the appropriate wallet based on the provided token and unlocks the key file. After that, a transaction signer is created, which is passed to the contract bindings that use it to create the transaction. After sending the transaction to the smart contract, the account gets locked again. This enables the unencrypted key to be kept in memory only as long as necessary to create the transaction. Events can also be listened to via the various contract services and are streamed to the caller.

The discovery service provides the user with the possibility to search for brokers and products by providing a search query (see Fig. 4). Brokers can be filtered by name and location and products by data type, frequency, and cost. The blockchain is scanned for brokers directly by the proxy, whereas a product query is forwarded to a broker that was specified by the user in the search query. In both cases, the filtered results are streamed to the caller.

Messages that are to be transferred from providers to consumers are encrypted using the crypto message service and forwarded to the specified broker. The public or private key of the respective Ethereum account is used to encrypt and decrypt the data using the (ECIES). This means that no additional key pair has to be created and no key exchange has to take place, since the public key of the consumer can be read directly from the device contract. The messages are pushed unencrypted to the proxy, which uses the public key of the consumer to encrypt the payload. The consumer pulls the message through a proxy, which again uses the token to determine the appropriate key file and uses the account’s private key to decrypt the payload.

A broker implements three services and makes two of them available via (gRPC). These three services include the message service, the dispute service, and the discovery service. A broker also has its own Ethereum account so that smart contracts can be called, which is necessary for dispute resolution.

The main task of a broker is fulfilled by the message service, which accepts and counts messages and puts them in a queue where they can then be pulled by the consumer. This enables the consumer to be offline while the provider sends the messages, but only a certain number of messages are stored in the queue to limit memory usage, and a broker also does not provide persistent storage. Furthermore, the prototype does not provide any means of authentication, which enables anyone to consume the messages from a broker. In future work, a broker should be expanded to include an authentication mechanism, which ensures that only the consumer who bought the data can pull the messages from the server. For example, token-based authentication could also be implemented here, whereby the user does not provide a username and password to receive a token but has to prove that it has the private key of a certain Ethereum account.

Like the proxy, a broker takes over the task of providing different products by entering a search query. As has already been mentioned in Sect. 6.2.1 the search query enables filtering by data type, frequency and cost. A broker scans all products saved in the product contract and streams the filtered results to the caller, which in most cases is a proxy that forwards the results to the consumer.

The last service is responsible for dispute resolution. If providers and consumers cannot agree during the settlement process, a dispute event is triggered on the blockchain. A broker listens for these events and sends a transaction to the corresponding settlement contract to resolve the dispute by providing the message count recorded by the message service.