Can we put our trust in a decentralized marketplace?

With the appearance of edge clouds, we foresee a scenario where application developers will need to buy multiple services such as edge computing, network latency and bandwidth guarantee, as well as mobility management from a potential variety of telecom operators.

As a result, to expose these services in the emerging 5G ecosystem, we can expect to see much tighter collaboration among telecom operators and cloud providers. And until such a thing happens, it will be difficult to realize the next generation of challenging 5G use cases.

Designing a marketplace

One possible way to expose and subscribe to all of these services is through a marketplace.

In the context of collaboration between telecom operators, cloud providers and application developers, this marketplace would have three roles:

1. to match the sellers and buyers, allowing them to negotiate a contract that defines the terms and conditions of usage of the service
2. to provide the tools to continuously verify that the terms are respected and possibly help to enforce them
3. to make it easy to re-negotiate or terminate contracts while staying within the boundaries defined by the first agreement

In this post, we will look into the first role: how can a marketplace help its members build enough trust to negotiate and sign a contract with a partner with whom they have no prior relation?

Marketplace: Centralized vs. decentralized

The three deployment options of a marketplace

There are three main ways for providers to expose their services : through a centralized marketplace, through a decentralized marketplace or through no marketplace at all.

In a centralized marketplace, any issue of trust is resolved by relying on a trusted third party. They take responsibility for the proper operation of the marketplace. The other actors trust them to police the platform (removing any misbehaving actor for instance), keep it secure by using the latest technologies, and mediate any disputes. Financial settlements can be managed by a trusted intermediary, which further adds some cost to the users. There are also other downsides to this deployment option: if relying on third parties completely lifts the burden for users, it can also make such marketplace quite opaque, with very little transparency for anyone but the organizations running it.

In contrast, with no marketplace at all, interacting with a new business partner can be more direct, however the partners must bear the responsibility alone. They need, on both sides, to have access to the resources and competences required to safely negotiate an agreement. This makes the process hard to automate and quite costly, both in terms of time and resources.

What we are investigating at Ericsson is an intermediate solution: a decentralized marketplace. In this case, the marketplace members agree on a set of business rules that will govern the transactions, and they are each responsible for taking part in running the marketplace infrastructure. The rules and infrastructure provide a framework that makes it possible to set up automated agreements. Moreover, as all members take part in the operation of the marketplace, we can avoid the centralization of power in the hands of one actor and make it possible for the platform to be very transparent. This also means, however, that the security of the platform relies on the technology itself and on its proper operation by the members.

Accountability and privacy in a decentralized marketplace

When dealing with a decentralized marketplace, there is no single entity that takes the responsibility for the proper operation of the marketplace. As a result, all guarantees must come from the technical platform. Not only does it need to be properly designed, but it also needs to be properly implemented, deployed and monitored. Moreover, all these guarantees need to be verifiable by any of the members of the marketplace, at any time.

Focusing on the issue of enabling contract negotiation between unrelated entities, we have identified a number of requirements that need to be fulfilled by the marketplace.

On a high-level, this issue boils down to accountability. As a member of the marketplace, for example, I want to be sure that my business partners will be held accountable for their actions in the marketplace. Going a little bit further, this can be split in two parts: the users must be held accountable for their actions and the marketplace must be able to account for actions performed by the users (for instance a contract they signed or a payment they made).

• Ensuring user accountability requires that every marketplace user is authenticated. Moreover, their identity in the marketplace needs to be linked to a legal entity that can be held responsible for their actions. As a result, access to the decentralized marketplace needs to be restricted to a set of entities that can be trusted to be, at least, accountable for their actions. This might be enforced, for instance, through a contract.

• Accounting for user actions (i.e. providing proof of user transactions) can be further divided in two components. Firstly, the marketplace needs to capture the nature of the action, what has been done, when, by whom. Secondly, the marketplace also needs to record the data associated with the action. For instance, a record would contain the fact that a given user signed a contract at a given time as well as the content of the contract. Beyond just saving the data, the marketplace also needs to ensure that it is kept as long as needed, is protected against tampering, cannot be repudiated and that there are tools and procedures in place allowing for an auditor to retrieve it when needed.

Finally, as marketplaces store sensitive data that should not be accessible by all the members of the marketplace, data privacy naturally becomes a critical feature. This makes it possible for the data owners to retain control of their data i.e. where it is stored and who has access to it. This can be used, for instance, to restrict the access to the details of a contract only to the parties involved.

Accountability and data privacy will be key to ensuring trust in any decentralized marketplace involving enterprises

Private vs. public blockchains

Public blockchains, such as Bitcoin and Ethereum, are open and require no permission to join. This means that anyone can become a participant without having a prior relation to any other node in the system. The way this blockchain works means that, if more than half of the computational resources are technically well behaved, their results will dominate any malicious or malfunctioning nodes. Such systems are also tricky for enterprises to monetize.

Private blockchains, on the other hand, can offer more monetization opportunities for enterprises. These are usually deployed in permissioned networks, which means that participants can only join with prior permission. Compared to public blockchains, private blockchain marketplaces employ strong identities, user management and protected data structures.

When it comes to deployment, private blockchains are most suitable for industry segments which somewhere between a public blockchain in an untrusted public environment and a distributed database hosted in a fully trusted internal deployment, such as banking.

To learn more, we recommend reading the Ericsson Technology Review article: ‘Facilitating online trust with blockchain’.

Private blockchain marketplaces

The qualities of a decentralized marketplace closely match the properties that can be expected from a private blockchain. In this section, we will detail how such a platform can be leveraged to implement the decentralized marketplace we described. We will not go into the details of a specific blockchain implementation, but rather stay at the level of the properties that are common to most of the private blockchains implementations that support smart contracts.

The first question for us to answer is the following: is our use case really suitable for blockchain? Comparing its characteristics to the “key technical properties of suitable use cases” from Ericsson’s technology review: Facilitating online trust with blockchain, we see that our use case is a good match. Indeed, the expected benefit of our solution is to present a shared trusted history of the marketplace transactions, holding the users accountable for their actions both present and past. The stakeholders are expected to be mostly mobile network operators and cloud providers. They are thus of similar standing and their respective reputation allow them to trust each other, at least partially. The realization of the sold services is independent of the blockchain, relying on it only to manage the business agreements. Based on this analysis, we expect our use case not only to be solvable with a blockchain solution, but also to really benefit from it.

Going further, the next logical step is to choose between a public and a private blockchain. For our use case, we have established that the access to the marketplace needs to be restricted to a set of actors that share limited trust. This matches the fundamental difference between private and public blockchains: for the former, the access is limited to a set of vetted participants whereas the latter is open to anyone. As a result, we believe that a private blockchain is the most suitable deployment option for our use case.

Smart contracts in a blockchain marketplace

Beyond this, are there any missing pieces needed to meet the requirements for our distributed marketplace? On a very high level, the platform provides three functionalities:

1. The ability to store arbitrary data in an immutable and non-repudiable way
2. The ability to define computer code that can execute over this data (smart contracts)
3. A detailed log of every action that altered the state of the ledger

The next step would be to develop a smart contract that defines a workflow for our blockchain marketplace and leverages these three capabilities to provide the guarantees we need.

How this structure would look in a simplified solution

In the above figure, you can see that every agreement between two parties is represented by a document. The structure of this document encodes all of the terms and conditions of the agreement, for instance its validity period, withdrawals period, price structure.

In addition to this data structure, the marketplace members also agree on the smart contracts that define all operations that can be performed on this document. For example, one party can submit it to its partner, sign it, terminate it, alter it. Every step in the lifecycle of the agreement is already defined in the smart contract.

In the end, when two parties are transacting, they only interact through the execution of that which is predefined in the smart contract. In the ledger, this will create a shared history composed of both the documents themselves as well as the logs of all the executions of the smart contract. If any dispute was to arise, this history can then be used to trace back the actions of both parties and resolve the dispute.

However, what has been described so far does not consider potential privacy requirements. Indeed, in its simplest form, a private blockchain makes the data available to all its members. Even if there are multiple technical solutions that exist to limit who has access to the ledger data and it is possible to design a solution that respects the privacy of the users, there is no silver bullet. Any such deployment would require careful considerations so as to not negate the other benefits of the ledger.

Takeaway insights

Based on the analysis of the requirements of our decentralized marketplace use case, we expected it to benefit from a private blockchain solution. Our expectations were confirmed through further investigation into how to design such a solution. By leveraging a private blockchain and smart contracts, it is possible to build a decentralized marketplace where business partners can interact, being confident that their counterparts will be held accountable for their actions.

Obviously, such a platform alone cannot guarantee that both parties fulfill their parts of an agreement. It does however make sure that all the tools are in place to swiftly resolve any dispute arising along the way.

Lastly, though a private blockchain does provide a sturdy foundation, it is not straightforward to build an application on top of it. The whole system needs to be carefully designed, implemented and deployed in order not to undermine this foundation. We will explore this in more detail in a following post. Stay tuned!

Learn more

Gain an understanding of the opportunities and challenges in blockchain in our Ericsson Technology Review articles:

• Creating the next-generation edge-cloud ecosystem
• Facilitating online trust with blockchain
• Service exposure: a critical capability in a 5G world

Read more insights on our future technologies page.