1 Introduction

A service marketplace enables IT service providers to sell software services and service consumers to discover and use services [15, 20]. Despite high hopes, service marketplaces have, so far, not been successful on a larger scale. Systems like the Universal Description, Discovery, and Integration (UDDI) registry have never attracted a critical mass [13]. Deficiencies in current service markets manifest in market barriers, low competition, insufficient service substitutability, insufficient service information, and high transaction costs [16]. A substantial body of work has addressed problems of insufficient service information by offering techniques to improve service descriptions (including service level agreements) and service discovery from a service-oriented computing perspective. Problems related to marketplace pricing strategy and incentive structures for marketplace participation, however, remain. In this paper, we focus on the role of trusted intermediaries in service marketplaces. Centralized marketplaces often lead to deficiencies in the form of lock-in effects and market barriers [8, 16]. Dependency on intermediaries can lead to disadvantages for buyers and sellers if their objectives do not align with those of the intermediaries [4, 7, 9, 11].

We propose a concept for a decentralized and trustless service marketplace which is not provided and governed by a single trusted party, but instead by a community of individuals that participate in the marketplace. The design and prototypical implementation of our marketplace system is based on distributed systems technologies that enable decentralization, in particular on a blockchain that can execute smart contracts. We introduce the concept of trustless intermediation in the context of service marketplaces and describe how service discovery, transaction settlement, and dispute resolution can be realized without a trusted third party. This design could potentially overcome fundamental problems, such as lock-in, of traditional centralized service marketplaces. Our system prototype contributes to the development of future blockchain-based decentralized (service) marketplaces and helps to identify technical and non-technical challenges.

2 Background and Related Work

A service marketplace is an online marketplace where suppliers can sell software services [15]. Service consumers can buy and use these software services for composing higher-level services and for building applications [20].

Centralized marketplaces provide mechanisms to facilitate efficient spot trades between large numbers of sellers and buyers by providing match-making and payment transaction processes that are accompanied by trust-building mechanisms, most importantly, reputation and dispute resolution systems. However, relying on reputation as a trust building factor alone can lead to entry barriers for new sellers from whom buyers are less inclined to purchase [8, 16]. A main problem of current online dispute resolution systems is enforcement, which is particularly challenging in cross-border e-commerce where no standardized global legal instruments for enforcing contracts exist [12]. Besides a marketplace provider, trusted intermediaries might offer additional market functions, in particular match-making (service and price discovery), transaction settlement, and legal/regulatory functions [10]. Reliance on trusted intermediaries can be problematic for buyers and sellers. Trust can be exploited or betrayed, for example, if a match-making intermediary can obtain higher revenues by matching certain buyers with certain sellers [4, 9, 11], if the marketplace provider forces sellers to vertically integrate with its technology platform [7], or in extreme cases if law enforcement take-down or “exit scams” terminate a marketplace [17].

The development of decentralized marketplaces is driven by a desire to establish systems without a central marketplace provider and without trusted intermediaries. Motivations include reducing barriers of entry [8, 16], reducing fees [2], increasing resistance to shut-down [14], and improving privacy [18]. There are a few initiatives for building decentralized anonymous marketplaces based on blockchain technologies, such as OpenBazaar, Beaver, and Ties Network. Blockchains are distributed peer-to-peer systems which implement a trustless shared public append-only transaction ledger [19]. Some blockchain systems, such as Ethereum [6, 21], support the deployment and execution of smart contracts. A smart contract is a set of automatically enforced digital rules which cannot be manipulated or censored in specification or execution. OpenBazaar [2] is a free and censorship-resistant blockchain-based marketplace for trading goods, using multiple crypto-currencies for payment and settlements. Transactions are performed directly between peers without the involvement of a trusted intermediary. Beaver [18] provides a Sybil attack-resistant, anonymous reputation system without relying on a trusted third party. A different blockchain-based marketplace design, described in the Ties Network Whitepaper [3], is to designate special roles to users, e.g., for resolving conflicts, and to make anonymity optional in favor of more traditional reputation-based trust-building approaches.

3 Trustless Intermediation

As a new idea, we introduce the concept of trustless intermediation which replaces traditional trusted intermediaries, such as centralized service registries and payment providers. We define trustlessness as a system property which guarantees rules of interaction that are known to and agreed upon by all participants of the system, and which cannot be unilaterally changed. These guarantees are enforced through, what we call trustless intermediation, a set of mechanisms for decentralizing the enforcement of rules in a system, thereby removing the need for and existence of trusted intermediaries.

In the following, we propose two main mechanisms for implementing trustless intermediation in a system: through (1) a set of smart contracts, and (2) supporting actors. By using smart contracts, the rules of interaction between sellers and buyers are transparent and self-enforced. If any participant deviates from the rules, the consequential actions, e.g., compensation and punishment, are also known and automatically enforced through smart contracts. Supporting actors provide functions that exceed the capabilities of smart contracts, yet, need to be carefully selected and incentivized, to avoid that they neglect or abuse the marketplace function that they have been assigned.

Based on this concept, we describe functions of a decentralized service marketplace from the perspectives of both service providers (sellers) and service consumers (buyers). We show how service registry, transaction settlement, and service delivery features can be realized with smart contracts and supporting actors in lieu of trusted intermediaries. Figure 1 illustrates the roles and functions in a blockchain-based decentralized service marketplace for a service lifecycle.

Fig. 1.
figure 1

Roles and functions in a blockchain-based decentralized service marketplace.

Full size image

Service Registry. A service registry enables basic match-making between service providers and consumers. Service providers can publish their service descriptions to a service registry and service consumers can discover services they need. We realize the service registry with a smart contract that contains references to service providers and service description documents. For this purpose, the service registry contract needs to maintain state of the provider-to-service mapping, allow providers to publish and update service descriptions, and enable consumers to find services they need. For decentralized service discovery, service description documents need to be replicated across multiple nodes in the network. To avoid trust, each consumer should receive and maintain an up-to-date replica of the entire service catalog. In case of updates or shutdowns of services, the impact should be as small as possible for the service consumers. Since providers can remove services from the service catalog and with that prevent purchases, it is desirable to support a reasonable phase-out process. One approach to incentivize timely announcements of service interface and usage changes is to collect a deposit from service providers on service registration. A smart contract serves as an escrow and only refunds the deposit if a version change was announced by sending a notification to the smart contract with a certain leadtime before service removal. If the announcement has not been made (within the agreed-upon leadtime), the deposit is paid out to the service consumers. A similar approach could be applied to breaking changes during updates.

Transaction Settlement. For each service on the marketplace, a service contract is deployed. This contract contains the business logic for payments and refunds. In order to consume a service, a user invokes the service contract to make a payment in a virtual currency and in the same transaction adds her authentication information to the contract, which is later needed for authenticating the consumer’s service requests.

Different payment models can be encoded in a service contract, such as:

  • Time slices: Once a consumer has selected a service, she subscribes to the service by paying a fee to gain access to the service for a certain time.

  • Utility computing: A service consumer pays for a certain type of workload, such as the number of requests, the operation types, the payload size, etc.

  • Subscription: A service consumer pays a subscription fee that gives access to a service up to a certain workload limit.

Service Delivery. The service providers needs to distinguish paid-for service requests from unpaid service requests. We consider two approaches:

  • Proxy Service: Requests are not sent to the target service directly, but to a proxy verifying the sender’s authority before forwarding the request to the designated target.

  • Signature Library: Sender and receiver both use a library to sign outgoing messages and validate incoming messages.

The Proxy Service approach simplifies service integration for both consumer and provider who do not have to take care of message integrity and caller authorization. On the downside, a provider-side Proxy Service would be a single point of failure for all services using it, and a Proxy Service that is powered by a supporting actor would require trusting a third party.

Using a Signature Library, consumer and provider can directly integrate functions for signing, and signature verification, respectively. Both parties are thereby enabled to freely choose which endpoints require authorization and how to handle errors, such as insufficient funds. On the downside, this solution shifts integration effort to consumer and provider.

Following our main objective of trustless intermediation, we prefer the Signature Library approach, which consists of the following three steps:

  1. 1.

    The consumer signs the payload of service requests. Along with the payload, the signature and public key are sent in the request header.

  2. 2.

    Signature and public key are used by the receiving service to verify that the message body has not been altered.

  3. 3.

    The service verifies that the address belongs to a paying service consumer, processes the request, and sends a success or error response back.

This process requires consumer-side and provider-side service integration. Step 1 requires a signature library that must be used by the consumer to sign all requests that invoke services which have been purchased on the marketplace. Furthermore, a consumer might want to automate the process of making service payments to avoid request errors due to lack of funds. The provider needs to integrate a signature verification library to perform steps 2 and 3.

Dispute Prevention and Resolution. Disputes between provider and consumer can occur, e.g., if a consumer has paid for a service that is frequently unavailable. We identified the following approaches to prevent and resolve disputes: micro-payments, escrows, and escrows with supporting actors.

Micro-payments. One approach to dispute prevention is to allow service consumers to frequently buy short time slices or small units of service access. This limits the consumer’s monetary loss in case of a service unavailability. However, there is no direct punishment for the provider’s unavailability. As a disadvantage, a service consumer must continuously add deposits to the service contract.

Escrows. A service contract can contain an escrow mechanism. Service providers, for example, could be required to make a deposit to their service contract before offering a service. If a certain share of service consumers report dissatisfaction, the provider would lose that deposit and the escrow contract would use it to compensate consumers. This approach further eliminates trust that consumers would otherwise need when purchasing a provider’s service, but needs careful incentive design as sybil and collusion attacks need to be prevented.

Escrows with supporting actors. A supporting actor could serve as a monitoring agent who periodically checks service availability and stores the monitoring results in a smart contract (monitoring contract). These results can then be used to resolve disputes and compensate consumers, e.g., refund a consumer’s payment or force the provider to pay a fine in case of service unavailability. Here, the smart contract acts as an escrow and requires a provider deposit so that the fine payment is guaranteed. To incentivize participation in the marketplace, supporting actors need to be rewarded, e.g., by paying them a reasonable fee.

4 Decentralized Marketplace System

In the following, we describe Desema, our decentralized service marketplace prototype, which is available as open source software on Github [1]. Desema is a peer-to-peer system which connects service providers and consumers through a shared public blockchain network, Ethereum, and a distributed data storage system, IPFS. Figure 2 shows the high level system architecture with two Desema clients. The rich client offers marketplace users a web-based graphical user interface. On the left side is a service provider, Bob, who wants to sell API access to his service. For this purpose, Bob uses a local Desema client on his computer to register and publish his service. On the right side of Fig. 2 is a service consumer, Alice, who accesses Desema through her own local client. Alice finds Bob’s service in the service catalog, decides to consume the service, and agrees to deposit a payment. Her purchase is facilitated through the service contract. After the purchase, Alice integrates Bob’s service into her application. Her application invokes Bob’s service with a signed request. For signing a request, the private key of Alice’s user account is used. Afterwards, the request body is hashed and the hash is signed. The public key belonging to the private key used is added to the returned signature object, both of which are added to the request header. By calculating Alice’s address from her public key and comparing it to his list of paying consumers, Bob’s service can identify Alice as a paying consumer and verify request message integrity using a signature library.

Fig. 2.
figure 2

Desema system architecture.

Full size image

Trustless Distributed Data Storage. Business processes in Desema are managed on the blockchain. Storing service metadata and other larger data object on the blockchain would, however, be inefficient and expensive. As a solution to this problem, we introduce an approach for trustless distributed data storage by which only data references are stored on-chain. Instead of using an arbitrary name as an identifier, the identifier is computed from the off-chain stored data itself. Off-chain data changes would immediately change the on-chain identifier and invalidate the reference. Furthermore, data integrity can be checked at any time by computing the identifier from the original data in a smart contract and comparing it to the reference. For off-chaining Desema service metadata, we use the InterPlanetary File System (IPFS) [5], a public peer-to-peer file system which addresses files by their hashes. IPFS peers host their own files as well as copies of other’s files to ensure availability. Service metadata is stored off-chain in an IPFS directory structure which contains all service versions in separate sub-folders, and only a file reference address is stored in Ethereum. Using IPNS (InterPlanetary Name Space), we can also support mutable content at a fixed address. As IPNS requires cryptographic authorization by the service owner, trustlessness is not impacted.

Trust-limited Monitoring. Monitoring is performed by supporting actors. We need to ensure that those actors do not compromise the integrity of the marketplace by returning inaccurate monitoring results. Trust in monitoring agents can be limited by randomizing the assignment of monitoring jobs to agents. The assignment is performed by the monitoring contract because otherwise a trusted third-party would be needed. Since the Ethereum Virtual Machine (EVM) cannot generate random numbers, we let the monitoring contract generate pseudo-random numbers that are difficult to predict. As an extension to random assignment, multiple nodes could be assigned monitoring jobs for the same service, whereby monitoring results can be determined through a quorum consensus, thereby further limiting trust in individual monitoring agents.

5 Conclusion

In this paper, we introduce the concept of trustless intermediation in service marketplaces based on blockchain technology and discuss approaches to overcome fundamental problems of traditional marketplace systems, such as barriers of entry, transaction costs and lock-in. We propose a design in which trusted intermediaries that operate a marketplace can be replaced with a set of rules encoded in smart contracts and enforced trustlessly in a blockchain network. As a proof-of-concept, we present a prototypical implementation of the aforementioned concepts. Based on the experience that we gained by building the prototype, we identify decentralized application engineering challenges. In particular, we address limitations of on-chain storage and propose a solution for trustless and scalable distributed data storage. Open challenges include the design and development of more advanced and incentive-aligned approaches for trustless dispute resolution between service providers and consumers.