A Proof-of-Customer model for public permissioned blockchains; July 2020

This blog proposes a Proof-of-Customer model for public permissioned blockchains, like Sovrin and Ripple. This is an economic incentive model for validators, similar to the Proof-of-Work incentives for permissionless blockchains like Bitcoin and Ethereum, but without wasting lots of energy.

1. Introduction

An incentive model is one of the essential features of a blockchain, in order to warrant its long-term sustainability, by providing direct payment for the ‘right’ (short term) behaviour. The crux of an incentive model is thus to incentivize short term behaviour with a longer term objective in mind. Often, incentives assume a profit maximizing behaviour of agents. Energy-consuming Proof-of-Work cryptocurrency mining is the prevailing solution for permissionless blockchains like Bitcoin and Ethereum to keep the transaction validators (“miners”) economically incentivised. More environmentally-friendly incentive models are being developed, like Proof-of-Stake and Proof-of-Space & Time.

Whereas public permissioned blockchains (“distributed ledgers”) could use the same Proof-of-X models to incentivize transaction validators, such makes less sense. Validators of a public permissioned blockchain form an governed collaboration by definition. They could organise incentive models through their governance process. The organisational form governing a public permissioned blockchain may be a foundation, a commercial organisation, an association or other. Moreover, public permissioned blockchains may exist without cryptocurrency. Even if there is a cryptocurrency, it would managed by its governance process.

The incentive model of this blog is based on the following insights.

  • On the long term, a blockchain infrastructure has to be paid for. That is, by its customers, users or beneficiaries.
  • The validators run the blockchain infrastructure
  • The governance process needs to be maintained

This led to the idea: let validators be individually incentivised to attract paying customers.

This idea is not a new idea. This is for instance also the model by which the internet domain name system is financed. Nevertheless, we don’t see this notion often in the context of public permissioned blockchains. Most public permissioned blockchain are still early stage, in which venture capital and initial coin offerings (ICO) may be clogging the long-term business model. The proposed model focusses on public permissioned blockchains, as private blockchains typically combine the roles of customer and validator. The proposed model is generically applicable, independent of the type of transactions. These could be financial transactions, cryptocurrency transactions, identity-related registrations, provenance-related registrations or other.

2. Understanding the link between creating value and governance in public permissioned blockchains

Before introducing the Proof-of-Customer model, we would like to explain our view on the relationship between creating value and the governance in public permissioned blockchains. We view a public permissioned blockchain as a collaborative network, i.e. ‘a network consisting of a variety of entities (e.g. organisations and people) that are largely autonomous, geographically distributed, and heterogeneous in terms of their operating environment, culture, social capital and goals, but that collaborate to better achieve common or compatible goals, thus jointly generating value, and whose interactions are supported by a computer network’ (Camarinha-Matos & Afsarmanesh, 2004).

Figure 1: A public permissioned blockchain can be seen as a collaborative network

 

The core of Figure 1, the thick linked squares represent the connected validator nodes of the permissioned blockchain service. This is the infrastructure needed to write and read information, e.g. credentials definitions and distributed-identity keys, to a distributed ledger. The reading and writing to this ledger is in fact the service provided, by the Validators, to Customers. The quality of this service is interdependent on the availability and quality of other nodes in the network. The governance of the software that the nodes use and other terms of use, e.g. under which criteria new nodes (Validators) can join, are specified by the Common Core. Note that this can be a dedicated business, a foundation, a cooperative of Validators or just a governance process. It can be seen as a platform provider (T. R. Eisenmann, Parker, & Van Alstyne, 2008), as it determines what is in common for all Validators. It is important to understand that the Common Core assumes an interest of its own. The Common Core’s proposition is crucial to the Validators’ decision to participate as well as a core of the value proposition the Validators offer to the Customers.

The value of this infrastructure is basically determined by the number of Customers and the value the usage of applications, based on and including use of the infrastructure, represents for the Customers. Metcalfe’s law indeed states that the value of a network is proportional to the square of the number of users. Yet, this network is provided by a collective of Validators and specified by the Common Core.

The design of the governance of the platform, including the incentive structure, and the ecosystem must thus (see also Table 2):

  • achieve an as large as possible demand for the infrastructure by Customers,
  • jointly provide an infrastructure by Validators that sufficiently serves and scales with the demand at low costs, and
  • strike a balance between the value for Customers, the value for the Validators and the value of the Common Core

 

Validator perspective

 Common Core perspective

Growing the network of Customers

Commercial incentives to connect and serve Customers:

Local market knowledge

Portfolio of complementary services and the infrastructure

 General awareness of the infrastructure, its qualities and wide availability and typical use cases or applications

Scaling the network of Validators

Attractive business case for Validators, low barrier of entry and exit, freedom to develop attractive portfolio of complementary services

 Entry criteria, minimum performance criteria

Monitoring and fair competition

Reasonable cost for governance and overhead, improvement and recovery

Striking balance

Contribution to costs of governance and overhead, recovery

Contribution to Monitoring, e.g user satisfaction

 Proportional representation of Validators and Customers in decision making

Table 2: Design considerations of the governance of the platform.

Table 2 above, illustrates the two key perspectives that are relevant in designing a collaborative network. The individual Validator perspective indicates that it must be interesting enough for the Validators to join and stay in the network. The Common Core perspective is focused on establishing the value and preconditions for the network. This is not necessarily established by the individual incentives of the Validators, as each Validator’s individual incentive is a) dependent on other Validators and b) each Validator has a position outside the network as well (e.g. by complementary services). The three aspects (rows) in the table represent factors that affect the perspectives. A growing network of customers, by Metcalfe’s Law represents the value of the network as a whole. As this is at least part of the Validator’s business, there is an incentive to create a large network. The size of the network of Validators is of importance for the stability and quality of the infrastructure, and thus also for the offering of the Validator to its customers.

The aspect of striking the balance refers to the inherent potential conflicts of interest: there should not be one Validator that dominates the others or the Common Core, as that will diminish the value of the network, because other Validators may walk away and customers have no choice. And the Common Core should not dominate the Validators, as that will diminish the incentives of the Validators. However, upgrading the set of common features, available through all Validators and forthcoming requirements to the Validators, may bring additional value to the Customers.

We draw upon two key theories for this design challenge in collaborative networks

  • Multi-sided platform business models (T. Eisenmann, Parker, & Alstyne, 2006): the platform proposition (i.e. the Common Core) has to be attractive to Validators as well as Customers. And in order to establish network effects between these two a critical mass of Validators and Customers is needed.
  • Collective governance of the commons (Ostrom, 1990): the infrastructure is based on a pool of resources provided by the Validators and used by their joint Customers and each actor’s supply or use affects the quality of the pool.

The first theory puts forward how value is created and captured by Platforms exploiters. This includes controls like the requirements (or lack thereof) for onboarding of users, pricing, rights to monitor transactions etc. There is also insight in measures that platform users can take to deal with these controls. These include joining or even creating another platform (multi-homing) and uniting the interests of platform users in a representative body.

The second theory brings forward a set of design principles for governance in order to ensure proper use of the ‘pool of resources’. These principles include for example effective monitoring of the use of the pool (i.e. what do customers and Validators use and contribute and is that in balance) and effective and efficient conflict resolution (i.e. ensure that any conflict is resolved quickly and satisfactorily, such that the reputation of the network is not damaged).

We derive three key design criteria how the different roles can contribute to a flourishing network from these theories:

  • The freedom of Validators to provide additional services. By means of providing complementary value-added services. The network provides in principle access to a basic infrastructure to administer transactions. This infrastructure has only meaning in context of an application. Validators can appeal to local market conditions and specific Customer Journeys. The complete offering may include e.g. storage, APIs and probably an application in which the reading and writing of credentials makes sense. An example of a combination of infrastructure and application is the service of registering a company at the Chamber of Commerce. Such services, including access to the infrastructure, can be a source of income for the Validators as well as a driver for growth of the network.
  • The flow of money and control. The Validator is the gateway to the infrastructure, but how and how much contribution is given to the Common Core. How is determined how the Common Core spends the contribution and to what ends is it used? How transparent is this?
  • The participation of Validators in the governance of the platform. Platforms are subject to dynamics of the ecosystem and the conditions have to be adapted to these. The Validators are key actors in the both the operation and growth of the network.

The next section introduces the Proof-of-Customer as an incentive design principle and reviews it using the above key design criteria.

3. The model: “Proof-of-Customer”

The purpose of the “Proof-of-Customer” model is to provide a design principle aimed at a self-sustaining economic ecosystem for public permissioned blockchains by proper economically-determined incentives, but without the energy consumption associated with Proof-of-Work.

The following functional roles are distinguished.

  • Customer: party that wants to have a transaction written onto the blockchain.
  • Validator: party that validates transactions, and that runs a consensus algorithm with other Validators to write transactions onto the blockchain. This can be seen as a service to the Customer.
  • Common Core: organisational process that governs the public permissioned blockchain ecosystem and its Validators aimed at keeping the blockchain infrastructure sustainably available for the Customers.

Figure 3 sketches the main steps of the “Proof-of-Customer” model.

1) The Customer selects the Validator that serves its access and writes to the blockchain. It prepares and sends the ion. Economic forces will govern the prices that a Validator charges to its Customers for writing transactions onto the blockchain. Some Customers will choose a Validator for its lowest price, its ease of use, its privacy guarantees, excellent connectivity and performance or its attractive value-added or complementary services.

2) The receiving Validator receives the transaction. It checks whether it is a valid transaction according to the rules set in the governance, and it performs any KYC process if needed. Before submitting the transaction to the blockchain’s consensus process, it decides how received fees are distributed. This decision may be added to the transaction. The receiving Validator can assign all to the “Common Core account”, to its own account or according to some pre-set distribution.

3) A Validator owes some fee for the Common Core, to cover for the cost of governance, e.g. personnel, monitoring, etc. This fee could be according to list prices that have been determined by a community governance process. The list prices could be based on the type of transaction, the number of transactions, the number of bytes written, or other. There could also be fixed monthly fees and/or quantity discounts. If the amount assigned in step 2) to the Common Core account is less than what is owed, then the Validator can settle this out-of-band or according to some pre-set mechanism.

Though not shown in Figure 3, a Customer can easily check whether its transaction was properly written onto the blockchain by checking for it with other Validators, as reading from a blockchain is typically for free.

Figure 3: Proof-of-Customer model for permissioned blockchains

Figure 3: Proof-of-Customer model for permissioned blockchains.

The model is coined Proof-of-Customer, inspired by Bitcoin’s Proof-of-Work mining. In Bitcoin, the more proof-of-work that a miner delivers, the more it earns. Similarly, the more Proof-of-Customer that a receiving Validator delivers, the more it earns.

Dynamics of the governance – money flow
A likely early-days scenario is that most Validators will just use a default setting, where they receive no mark-up, and pay all received fees to the Common Core. Some Validators may start experimenting with slightly increased prices and see how many Customers appreciate its excellent offer despite the slightly higher price. Some Validators may try to lure Customers with a price that is below the Common Core list price to establish a broad customer base. Some Validators may integrate blockchain writes into their market proposition, and don’t even mention it to their Customers. Some Validators may even decide not to make a market offer at all, e.g. being a Validator out of charity or brand recognition, and not to compete for Proof-of-Customer earnings.

The pricing choices of the Validators will provide the Common Core process with valuable market information. For instance, if the Validators collectively increase their prices, this may indicate that the market value of blockchain writes has increased and/or that the market friction to become Validator has become too high. This may prompt a study and possibly a decision by the Common Core governance process.

The Common Core remains responsible for assuring that Validator-ship does not become a scarce resource. When the market justifies this, there could be many Validators in order to have sufficient amount of read and write capacity for the blockchain. When prices exceed a certain threshold, and the role of Validator becomes attractive, then any actor may decide to become a Validator. E.g. we can expect some larger Customers of the blockchain service to make this make-or-buy decision. This economic mechanism should refrain Validators from demanding excessive prices.

When the Common Core revenues start exceeding its operational cost, this should be observed by all participants in the blockchain ecosystem. In such case, Validators are likely to provide back pressure on the Common Core list prices, as it cuts into their bottom line. This would prompt the Common Core process to reconsider the Common Core list price.

4. Discussion

We will briefly discuss the Proof-of-Customer incentive design principle following the key design decisions based on platform business model theory and principles for good governance, see Table 4.

Key design decision

 

Proof-of-Customer

 

Freedom for Validators

 

Validators have substantial freedom to create a suitable portfolio of services and play with prices. A low level of entry could ensure competition. This freedom puts the Validators in a frontline to serve their Customers’ interest and thus grow the network and its usage. The blockchain network can be considered a shared resource for the Validators.

 

Flow of Money and control

 

The Validators are the primary recipients of incoming money. They will have to cover for the shared costs associated with keeping the network in condition.

 

Participation of Validators in governance

 

Although not explicitly addressed by the model, active participation of Validators in governance of the Common Core is likely essential for its success.

 

Table 4: Evaluating the Proof-of-Customer model.

The Proof-of-Customer model is definitely not the only incentive model for public permissioned blockchains. Two prominent public permissioned blockchains are Ripple and Sovrin. Currently, neither of these blockchains have an explicit incentive model for its validators. Ripple assumes that its validators have a business interest and that they run their validator nodes to provide proper access to their own customers. Sovrin is still ramping up and apparently the reputation value of being a Sovrin validator (“Steward”) is a sufficient incentive for the time being. Sovrin is planning to introduce a centrally governed algorithmic distribution of received fees among its validators. This and other incentives models are being discussed in the Sovrin Incentives Taskforce, including a Proof-of-Contribution-to-Consensus model and the present Proof-of-Customer model. Also combinations of incentive models may be possible.

We consider the Proof-of-Customer model the most transparent and distributed, as the distribution of fees is made visible on the blockchain, it incentivizes individual validators, it pays for its governance processes and it focusses on attracting customers, which provides value to the ecosystem as a whole. In contrast, we feel that a Sovrin-style algorithmic distribution of fees may be problematic for several reasons. It gives the governance process of the algorithm a too centralistic/powerful position in the ecosystem. This may lead to an inward focus, as validators may want to please the governance process and its algorithm, which may shift attention away from the actual customers. In the worst case, it may make the validator system instable.

All of this remains speculation. Simulation-based studies may provide further insight the behaviour of Customers, Validators and the Common Core of permissioned blockchain, depending on the used incentive model. This may provide some assurance, before introducing an incentive model into an operational blockchain ecosystem.

Oskar van Deventer and Frank Berkers

Camarinha-Matos, L. M., & Afsarmanesh, H. (2004)
Collaborative networked organizations. A Research Agenda for Emerging Business Models.

Eisenmann, T., Parker, G., & Alstyne, M. W. Van. (2006)
Strategies for Two- Sided Markets.
Harvard Business Review, 84(10), 12. https://doi.org/10.1007/s00199-006-0114-6

Eisenmann, T. R., Parker, G., & Van Alstyne, M. W. (2008)
Opening Platforms: How, When and Why?
SSRN Electronic Journal. https://doi.org/10.2139/ssrn.1264012

Ostrom, E. (1990)
Governing the commons: The evolution of institutions for collective action.
Cambridge university press.

 

Blog
Contact

Dr. ir. Oskar van Deventer

  • Scientific Coordinator
E-mail