# A General and Configurable Framework for Blockchain-based Marketplaces

Andrea Merlina<EMAIL_ADDRESS>Roman Vitenberg<EMAIL_ADDRESS>Vinay
Setty<EMAIL_ADDRESS>University of Oslo, Problemveien 7, 0315 Oslo, Norway
University of Stavanger, Kjell Arholms gate 41, 4021 Stavanger, Norway

###### Abstract

The first generation of blockchain focused on digital currencies and secure
storage, management and transfer of tokenized values. Thereafter, the focus
has been shifting from currencies to a broader application space. In this
paper, we systematically explore marketplace types and properties, and
consider the mechanisms required to support those properties through
blockchain. We propose a generic and configurable framework for blockchain-
based marketplaces, and describe how popular marketplace types, price
discovery policies, and other configuration parameters are implemented within
the framework by presenting concrete event-based algorithms. Finally, we
consider three use cases with widely diverging properties and show how the
proposed framework supports them.

###### keywords:

marketplace, blockchain, framework, auction

##  1 Introduction

The online marketplaces with the most significant global net sales [1] are
centralized. Centralization has been a traditional design approach because it
limits the overhead in the decision-making processes while providing a single
reference point for national law and regulation compliance. On the other hand,
from an economic perspective, centralization goes hand in hand with monopoly,
resulting in price control, unilaterally imposed commissions, and disclosure
control over information [2]. Besides, data integrity cannot be easily
validated by external auditing, and the quality of protection against attacks
is primarily up to the organization that owns the marketplace infrastructure.

Blockchain seems to be a natural choice as a decentralization paradigm for
marketplaces, which would confer the benefits present in numerous virtual
currency systems. Decisions in blockchain are inherently transparent, whereas
the ledger of transactions is secure and tamper-proof. Studies [3, 4] indicate
that, for a high volume of users, blockchain-based marketplaces are
significantly cheaper than their centralized counterparts.

Unfortunately, there has been no systematic study of challenges that a
blockchain-based marketplace design needs to overcome. Many marketplace
policies are based on the relative order of bids in real time, which is
impossible to implement over a blockchain. It is furthermore essential to
define the organizational model and consider the incentives of each entity.
While the exploration of blockchain-based marketplaces has already started [5,
3, 6, 4, 7, 2], existing proposals focus on a single specific application
domain and marketplace policy, as well as a concrete blockchain system.

In this paper, we place blockchain-based marketplaces relative to other
classes of marketplace implementations by considering the properties of each
class. We outline the challenges and, to the best of our knowledge, propose
the first generic encompassing framework for blockchain-based marketplaces.
The framework solves the above challenges and supports a variety of
configuration parameters at the application level (such as price discovery and
bid matching policy) and the blockchain level (such as consensus protocol or
blockchain type). The parameters can be set at the deployment time or
dynamically on a per-trade basis. We present concrete algorithms constituting
the framework and illustrate how the framework supports three use cases with
widely diverging properties: an auction of physical goods, a logo design
contest and a job advertisement.

##  2 Background

###  2.1 Background on marketplaces

A marketplace is a platform that facilitates the sale of goods and services in
exchange for money. Prior to the exchange, buyers and sellers advertise
trading items, place bids for trading items, and discover a matching bid for
each item. The process of setting the item price is called price discovery
[8]. Common types of price discovery policies are fixed price and auction [9].
In the fixed price policy, the buyer either accepts or rejects the price,
similar to brick-and-mortar stores. In an auction, a well-defined negotiation
phase takes place, and at its conclusion, the winning bid sets the price.

A seller may optionally set a minimum acceptable item price for an auction,
called reserve price. A reserve price may be made public or kept secret.

Within the auction policy type, commonly used price discovery policies include
the following:

English auction — Buyers compete by raising their bids, which are made visible
to other buyers. If the highest bid is not challenged for a certain amount of
time, the item is sold to the bid proposer.

Dutch auction — A high starting price is set by the seller and is periodically
decreased using fixed decrements until either a buyer accepts it or the
seller’s reserve price is met. In the latter case the item remains unsold.

First-price sealed-bid auction — This type of auction is also known as blind
auction. Bidders propose their bid once and within a time window, without any
knowledge of the other participant’s offers.

Vickrey auction— Sometimes called sealed-bid second-price auction, it is
similar to the blind auction, however the highest bidder pays the second high
bid rather than its own.

Reverse auction— In reverse auctions, the buyer publishes a request for an
item or service. Sellers compete by proposing bids with decreasing prices or,
differently, with increasing quality. This is commonly used in corporate
procurement departments that are in need of a service while trying to optimize
the contractor’s cost.

Additionally, the policies can be mixed to form hybrid versions. At the end of
the price discovery phase, the matching bid is established, and the actual
trading transaction may take place. A regulatory infrastructure is in place in
marketplaces to deal with misbehaviors at various phases. Furthermore, a
dedicated escrow entity may be employed to resolve disputes between the
trading parties.

###  2.2 Background on blockchain

A blockchain is a data storage solution consisting in a sequence of blocks
growing over time. Each block stores a group of immutable transactions and a
hash pointer to the previous block. A blockchain is maintained by a
distributed system where a network of nodes with misaligned interests agrees
on proposed transactions and securely records them. Every transaction causes a
change of state in the blockchain, which is validated by the nodes, thereby
providing consistency and total ordering of transactions.

The permission to become a node and the associated access policies
characterize the distinction between the two different blockchain types:
permissioned and permissionless. Permissioned blockchains such as Hyperledger
Fabric [10] have tight identity control, while permissionless ones such as
Ethereum [11] allow open participation without disclosing identities. Several
works have investigated permissioned and permissionless systems and their
differences [12, 13].

Blockchain uses a consensus protocol to maintain a consistent state among the
validating nodes. Every state update is signed and cryptographically linked to
the previous one so that any change is detectable by the nodes. This
construction provides strong guarantees about integrity and authenticity.
Blockchain storage requirements grow over time, as transactions are being
generated and added to the chain. To cope with the growth, some systems may
perform pruning of historic transactions, deleting obsolete information.

##  3 Marketplace properties

Figure 1 illustrates properties essential for marketplaces. The properties are
grouped into four categories. Electronic marketplaces may be centralized or
distributed in terms of both authority and deployment. Distributed
marketplaces include the properties of electronic marketplaces, while
blockchain based marketplaces are a subclass of distributed ones, thereby
including all of their properties.

Figure 1: Marketplace properties

###  3.1 Properties of a generic marketplace platform

A marketplace platform is general if it supports various trading items, market
models, and policies. A system is modular if its components are logically
decoupled, and the implementation of each component can be easily replaced
without affecting other components. For instance, a modular blockchain-based
marketplace supports different consensus protocols and price discovery
policies without changes to the rest of the system. Configurability is the
capability to support a variety of configuration parameters in order to tailor
the platform to specific functional and non-functional application
requirements. While some parameters must be set at deployment time, others can
be configured separately for each trading item or transaction, at run-time.

###  3.2 Electronic marketplace properties

Security — A system is secure if it can successfully accomplish its design
goals without any unintended side effects, despite impediments and threats
that might subvert the system. An example of such an impediment would be
rational behavior: an entity may deviate from the prescribed protocol for the
sake of its own gain or benefit.

Liveness — A system is live if it can progress over time in its operation. For
marketplace platforms, it means that associated functions, such as
advertisements and bid placements, continue unimpaired.

Fairness of trade — A marketplace is considered fair regarding the trading
process if both the buyer and the seller receive the agreed trading item and
the payment respectively [5]. This property is violated, for example, if the
buyer receives the payment yet keeps the item.

Fairness of matching — The matching of buyer and seller is fair if winning bid
selection for the trading item correctly follows the matching policies. This
property is attained either by transparency and verifiability (when the
marketplace authority is decentralized) or by trust in the organization that
deploys the marketplace and performs the matching.

Legal and regulatory system— Marketplaces must possess a legal infrastructure
that regulates permitted behavior on the platform, thereby contributing
towards correct functioning of the marketplace [8].

###  3.3 Distributed marketplace properties

Decentralization of authority— The control over the deployed marketplace
platform is shared between a group of organizations. For the sake of
decentralization, every buyer and seller must be represented by a node in the
blockchain network, either through direct ownership or a trusted proxy.
Decentralization of authority promotes transparency and decreases the risk of
arbitrary decisions.

Distributed platform and availability— A system is distributed if its
operations are implemented by a set of components running on different
machines, which orchestrate themselves by exchanging messages and appear to
operate as a single process. Buyers and sellers have coherent experience of
the marketplace due to this illusion of a single process.

###  3.4 Properties of blockchain-based marketplaces

In this paper, we claim that blockchain-based marketplaces improve distributed
marketplaces by inherently providing a number of desirable properties. While
the same properties might potentially be attained by using alternative
technologies, they are innate to blockchain.

Inherent integrity — This property is satisfied when the system is resilient
to data tampering, both malicious and unwitting. Blockchain design assures
such resilience through consensus and cryptographic mechanisms.

Inherent authenticity — Authenticity refers to preventing counterfeit actions.
Digital signatures and other cryptographic primitives are extensively used in
blockchain design to authenticate senders of transactions and messages,
thereby promoting authenticity.

Inherent transparency and decentralization of authority — These properties
lead to many benefits, including censorship resistance and fairness.
Centralized marketplaces are susceptible to censorship because they are
controlled by a single authority, which may unilaterally adopt policies
discriminating individual buyers and sellers or preventing items or bids from
being submitted to the platform. Fairness of matching is facilitated because
any observer can assess it efficiently and objectively. If the trading items
are purely electronic and stored on the blockchain, fairness of trade can be
easily monitored as well.

##  4 Marketplace model

Figure 2: Marketplace architecture and workflow. Dashed arrows/boxes represent
optional steps/entities.

At the organizational level, the system consists of nodes deploying the
blockchain. The marketplace platform is implemented as a software layer atop
blockchain; both permissionless and permissioned blockchains are supported,
though the reliability, performance, and other nonfunctional properties might
differ. Every organization or individual user must either directly run a
blockchain node, or connect to a trusted blockchain node representing the
user. Depending on the blockchain type, there might be a dedicated consortium
of organizations deploying the blockchain. Alternatively, the nodes may self-
organize in a peer-to-peer fashion typical of permissionless blockchains.

Each node plays one or more roles. Suppliers and consumers are core
marketplace roles. Escrows and bid evaluation committees are optional roles
that may or may not be used in accordance to the requirements of the use case.
At the blockchain level, every node running the marketplace and recording the
blockchain state acts as a validator for the transactions submitted to the
marketplace, blocks recorded, and correctness of matching. A subset of nodes
play the role of block proposers whose task is to extend the blockchain by
proposing new blocks; the subset depends on whether the blockchain is
permissioned or permissionless.

At the marketplace layer, the supplier is the role providing the trading item.
The supplier is typically a seller, but it can be a buyer (of the provided
service or item) in the case of reverse auctions. Consumers compete for the
trading item by placing bids following the price discovery policy. A subset of
all nodes may play the role of a bid evaluation committee in the context of a
given trading item.

As mentioned, the bid evaluation committee is optional. In general, matching
consists in evaluating individual bids and ranking them. When both evaluation
and ranking follow an objective algorithm, which, e.g., selects the highest
bid offered, it can directly be performed by every blockchain node so that no
committee is required. However, the matching may be based on subjective
evaluation, such as that of artistic quality. When the evaluation is multi-
dimensional, ranking may require subjective consideration of multiple
evaluation criteria, as we exemplify in our use cases in Section 9. If the
evaluation and/or ranking is subjective, it is performed by a committee of
experts external to the trade. While the bids are stored on blockchain, there
might be additional interaction between the committee and consumer that
happens off-chain. If both evaluation and ranking are subjective, the
committee simply submits a blockchain transaction that declares the winning
bid. If the evaluation is subjective but the ranking is objective, the
committee stores evaluation of every bid on blockchain, thereby achieving a
certain degree of transparency.

Note that a single system may integrate the marketplace and cryptocurrency
deployment by allowing transactions of both types. In fact, existence of
cryptocurrency is mandatory in permissionless blockchain because of the need
to pay the transaction inclusion fees and deposits. It is optional in
permissioned authenticated blockchains.

##  5 Challenges

A fundamental challenge that any distributed marketplace faces is the
inability to establish the relative order of bids reliably. The order is
essential to many trade types such as English or Dutch auctions. A centralized
authority such as eBay [14] records the order in which it receives bids.
However, if the authority is decentralized, such a simple centralized solution
is infeasible. In particular, the order in which bids are included into blocks
in a blockchain-based marketplace does not strictly correspond to the order in
which the bids were issued. We solve this challenge by replacing the strict
first bid condition in all price discovery policies by a window during which
bids of equal value can be proposed. The windows are measured in the number of
blocks rather than real time. They are furthermore objective because all
blockchain nodes observe the same sequence of blocks. At the end of a window,
the winning bid is determined by applying a pseudo-random function to the list
of all bids included within that window. The application of a pseudo-random
function is similar to the technique used in Algorand [15] for a different
purpose of consensus committee selection.

Another fundamental challenge is incentivizing the entities of a blockchain-
based marketplace to follow the protocol. In a permissioned blockchain that
authenticates the entities, legal action can be taken against the suppliers
and consumers that do not follow the rules of the trade after the matching has
been completed, or against a block proposer that does not propose blocks or
that includes incorrect data into block transactions. Yet, both suppliers and
consumers need to pay fees to the escrow, to the bid evaluation committee (if
it exists), and to organizations deploying the blockchain. The exact structure
of those fees is subject to the research in economy and left for future
research.

In the case of permissionless blockchain without authentication, however,
additional mechanisms are required. Block proposers are incentivized by
transaction inclusion fees, which may also need to be covered by suppliers and
consumers. Additionally, the suppliers commit to the advertised items by
placing a deposit on the blockchain, which is returned after the successful
completion of the trade or if a matching bid has not been found. Similarly,
the consumers place a deposit on the blockchain, which is returned after the
successful completion of the trade or after the designation of another bid as
matching.

##  6 Solution framework

We propose a general, modular, and configurable framework that supports
different market models in a single architecture. The framework presentation
in this section is complemented by the discussion of configuration parameters
in Section 7 and of use cases in Section 9.

Marketplace functionality generally consists of (a) matching sellers with
buyers and (b) trading. We present matching in Sections 6.1 and 6.2 and
trading in Section 6.3.

The marketplace architecture and the workflow for matching are shown Figure 2.
The workflow includes three mandatory steps: (1) Item advertisement, (2) Bid,
and (3) Item assignment. Optional steps are represented with dashed arrows.
The advertisement may include “secret” information, such as reserve price at
an auction, which will only be revealed after all bids are placed and the sale
ends.

Table 1: Events generated by blockchain, suppliers, and consumers, and handled
by the framework

[t]  Event Mandatory parameters Optional parameters Parameter Type Parameter
Type user item ad. request tradingItem tradeType saleDuration needRevelation
tItem tType $\delta_{\rm{sale}}$ revFlag domain-specific enum (see Sec. 7.1) n
of blocks boolean startingPrice payment maxDurationNextBid
maxDurationRevelation maxDurationEvaluation minimumBidIncrement
reservePriceHash evalCommittee deposit stPrice P $\delta_{\rm{bid}}$
$\delta_{\rm{reveal}}$ $\delta_{\rm{eval}}$ $\Delta_{\rm{bid}}$ resPHash
evalCom D numerical cryptocur. n of blocks n of blocks n of blocks numerical
numerical identity sets cryptocur. user bid request itemAdvertisement
bidContent A content a tuple domain-specific payment deposit P D cryptocur.
cryptocur. block inclusion1 block B

  * •

1 inclusion of a new block in the local copy of the blockchain

The framework is implemented as a collection of handlers for events generated
by the user and blockchain. Table 1 shows the list of handled events. Item
advertisement and bid proposal are initiated by the user who deploys a
particular node. New blocks, on the other hand, are received from the network
and their inclusion in the local copy of the ledger triggers a multitude of
derived events, such as registration of new item advertisements or bids, sale
expiration, etc.

Table 2: List of primitives used in the framework Entity |  Primitive |  Input |  Output
---|---|---|---
Blockchain |  addTxToPropBlock broadcastTx |  Tx Tx |
Use case developer |  customObjEval customObjRanking custom valida- tion callbacks |  bid bidScores |  bidScores winningScore

Table 2 shows the primitives provided by the blockchain and use case
developers that our framework utilizes. broadcastTx disseminates a transaction
to other blockchain nodes (e.g., miners in Bitcon or orderers in Hyperledger)
for inclusion into a new block. In some cases, a block proposer creates a new
transaction (such as an assignment of a bid to a trading item) upon processing
an event. Every block proposer performs the same processing and creates the
same transaction in such cases. Therefore, there is no need to disseminate the
transaction throughout the network. Instead, addTxToPropBlock adds the
transaction directly to the local pool of outstanding transactions maintained
by the block proposer, to be included in the next proposed block.

When the use case developer wants to employ objective evaluation of bids (see
Section 4), she needs to implement a customObjEval function that takes a bid
and returns a possibly multidimensional score for that bid. Similarly, when
the use case employs objective ranking of bids, the developer needs to
implement a customObjRanking function that takes a collection of scores
produced in the evaluation (by the committee or by customObjEval) and returns
the winning score. The validation of transactions and blocks is performed
collectively by the blockchain, marketplace platform, and use case developer.
The blockchain validates blocks and transactions as usual. The platform
validates that, e.g., deposits are present in the bid or item advertisement
and that the price in the bid follows the rules. However, the use case
developer may want to perform further application-specific validation, e.g.,
about the content of the bid. To this end, we allow the developer to define a
custom validation function customValCallback that the platform calls back.

Algorithm 1 shows the handling of user-initiated events, which simply consists
in creating a corresponding transaction and broadcasting it to the network.
The only involved element is handling of reserve price: the supplier needs to
commit to a reserve price upon the advertisement and disclose it after all the
bids are placed. This is achieved by supplier (a) computing a secure hash of
the reserve price and including the hash in the advertisement and (b)
broadcasting an additional “revelation” transaction after the bidding ends.
Since the hash inclusion acts as a cryptographic commit, the supplier cannot
modify the reserve price later without being detected. Algorithm 2 presents
handling of the block inclusion event. Every node validates the block first
while the rest of the handling depends on the role of the node. We present
processBlockBySupplier, processBlockByConsumer, and processBlockByProposer in
Section 7.3. validateBlock performs validation at the marketplace level and
additionally invokes a handler that the use case developer may implement. We
omit the code for validateBlock due to its straightforwardness.

Input: tItem, tType, $\delta_{\rm{sale}}$, revFlag, stPrice, P,
$\delta_{\rm{bid}}$, $\delta_{\rm{reveal}}$, $\Delta_{\rm{bid}}$, resPrice,
evalCom, D

1

2

3upon  _user item advertisement request_ :

4

5 resPHash $\leftarrow$ undefined

6

7 if  _resPrice is defined_ then

8 resPHash $\leftarrow$ compute a secure hash of resPrice using a random salt

9

10 A $\leftarrow$ create an item advertisement tx with (tItem, tType,
$\delta_{\rm{sale}}$, revFlag, stPrice, P, $\delta_{\rm{bid}}$,
$\delta_{\rm{reveal}}$, $\Delta_{\rm{bid}}$, resPHash, evalCom, D)

11

12 blockchain.broadcastTx(A)

13

Input: A, content, P, D

14 upon  _user bid request_ :

15

/* In practice, we need to invoke a callback implemented by the use case
developer, which would preprocess the content */

16

17 $bid$ $\leftarrow$ create a bid tx with (A, content, P, D)

18 blockchain.broadcastTx(bid)

Algorithm 1 Handling user-initiated events

1

2

3upon  _reception of the new block to be appended in the local copy of the
blockchain (block B)_ :

4

5 isBlockValid $\leftarrow$ validateBlock(B)

/* Block validation is split between the underlying blockchain, our platform,
and use case developer, who can implement a callback */

6

7 if  _$\neg$ isBlockValid_ then

8 return

9 if  _$n$ is block proposer_ then

10 processBlockByProposer(B)

11 if  _$n$ is supplier_ then

12 processBlockBySupplier(B)

13 if  _$n$ is consumer_ then

14 processBlockByConsumer(B)

Algorithm 2 Processing new blocks by node $n$

###  6.1 Trade advertisement

The trade begins with an item advertisement in which the supplier describes
the trading item and its metadata, and configures per-item parameters. The of
list parameters for the item advertisement is shown in Table 1. Mandatory
parameters need to be specified for every trade type, while the combination of
optional parameters varies based on the trade type. We describe the
configurable parameters in depth as well as their effect on specific
algorithms in Section 7.

Regarding the economic aspects and incentives, an item advertisement may need
to include several payments in cryptocurrency: (a) a standard transaction
inclusion fee for the benefit of block proposers in case of permissionless
blockchain, (b) a committee fee if the evaluation committee is used, (c) an
escrow fee if an escrow is used, (d) a deposit used as a collateral for faulty
trade items and for not revealing reserve price in time, and (e) a payment for
the services in case of reverse money flow used, e.g., in the use case in
Section 9.2. Each of these payments is used in a subset of scenarios and thus,
optional from the platform point of view. However, they might become
compulsory in a specific use case. Their presence may be enforced by a custom
validation callback. As mentioned in Section 5, the exact structure of the
fees is left for future research in economy. However, we explicitly show how
to handle the deposit and payment for the services in our algorithms.

Item advertisement results in a transaction that is first validated by the
validators and included in a block by the block proposer. The block is
appended to the blockchain according to the consensus mechanism.

###  6.2 Bidding, matching, and transaction settlement

Consumers bid for the advertised item according to the trade type. A bid
transaction is accompanied by a number of optional remittances. The list of
remittances is identical to that for item advertisements, though in each
specific use case, different remittances will be compulsory for bids. For
example, the payment for services needs to be provided either by suppliers or
consumers, depending on the money flow.

When the bidding phase ends, there might be an optional window of blocks that
is either used by the supplier to reveal reserve price or by the committee to
evaluate the bids and place the rankings on the blockchain. Once the bidding
and the optional window end, we say that a trading item is ready for matching.
At this point, we can compute the matching, assign the item to the winning
bid, perform the trade, and return the deposits placed with losing bids to the
consumers.

The way it is done in a blockchain-based marketplace, however, has to consider
the incentives of nodes. The most logical way would be for each supplier and
consumer to monitor the blockchain and propose relevant transactions when a
trading item of interest is ready for matching: if a consumer has lost in the
bidding, it will request the deposit back. A supplier and a winning consumer
will request to assign the item. The disadvantage of this scheme is the
proliferation of messages due to broadcasting transactions by all the entities
active in the trade. We use an alternative mechanism: the block proposer
itself monitors the blockchain for trading items ready for matching, computes
the matching, and includes the transactions of item assignment and deposit
returns into its own block. In a permissionless blockchain, the block proposer
will be incentivized to perform these operations by transaction inclusion
fees.

Block proposers constantly check if the specified block number for an
expiration has been reached and, in the affirmative case, include an item
assignment transaction into the block that will be proposed. The trade does
not happen if there are no bids that satisfy the requirement of the matching,
therefore in such cases both bids and deposits are reverted back to their
owners. In the cases in which the supplier failed to include an expected
revelation, the deposit of the supplier is kept as a fine.

###  6.3 Trading

When the trade is entirely electronic, it is considered concluded upon the
item assignment inclusion into the ledger. This applies to the use case of
logo contest considered in Section 9.2. However, in other cases, there is a
need for an external mechanism supporting the trade of physical goods. This is
commonly achieved by introducing an escrow that monitors the trade through a
number of known cryptographic mechanisms extensively studied in [16]. Since
the transfer of physical good is inherently centralized, it might be
infeasible to replicate the delivery involvement of escrow and make it
blockchain-based. However, the supplier, consumer, and escrow involved in the
trade may record their steps and operations in the ledger, thereby
facilitating transparency and mitigating the centralized nature of escrows.

In case of disputes, an arbitration request is raised either by the supplier
or the consumer. The request reaches the escrow and is stored on the
blockchain. The latter investigates the dispute and selects the entity to be
refunded through a dispute resolution transaction. If, on the other hand, the
exchange process is finalized in its entirety without disputes, the deposit is
unlocked after a safety window of blocks. In this case, by using optimistic
escrow protocols [16], supplier and consumer can manage and spend the deposit
without requiring any further action by the mediator.

Input: block $B$

1

2

3func  _processBlockBySupplier_ :

4

5 foreach  _item assignment $\in B$ for an item advertised by $n$_ do

6 notify the user about the assignment

7 foreach  _sale expiration for an item advertisement $A$ by $n$ due to $B$
reaching $A.\delta_{\textrm{sale}}$_ do

8 if  _$A.\textit{revFlag}$_ then

9 Tx $\leftarrow$ a new transaction with reserve price matching
$A.\textit{resPHash}$

/* In practice, the supplier would wait for an additional safety window before
revealing the reserve price */

10 blockchain.broadcastTx(Tx)

Algorithm 3 Block processing by supplier $n$

1

Input: block $B$

2

3

4func  _processBlockByConsumer_ :

5

6 userAdvInterest $\leftarrow$ list of item advertisements the consumer user
has expressed interest for

7 blockNum $\leftarrow$ # of block $B$

8

9 foreach  _A $\in$ userAdvInterest_ do

10

11 if  _$B$ contains item assignment for $A$_ then

12 notify user about item assignment

13 continue

14 adBlock $\leftarrow$ block in the ledger s.t. $A\in\textit{adBlock}$

15 adBlockNum $\leftarrow$ # of adBlock in the ledger

16

17 endSaleBlockNum $\leftarrow$ adBlockNum $+$ $A.\delta_{\rm{sale}}$

18

19 if  _blockNum $>$ endSaleBlockNum_ then

20 continue

21 adBids $\leftarrow\\{\textit{bid}\,|\textit{bid}$ is for $A$ $\land$ bid
$\in B$ }

22

23 if  _adBids $\not=\emptyset$_ then

24

25 if  _A.tType $=$ english auction_ then

26

27 notify user about
$\textit{max}_{\textit{bid}\in\textit{adBids}}|\textit{bid}.P|$

28

29 if  _A.tType $=$ dutch auction_ then

30

31 bid $\leftarrow$ select a random bid $\in$ adBids

32 notify user about $|$bid.P$|$

33 else

34

35 if  _A.tType $=$ dutch auction _ then

36 $\textit{diff}\leftarrow$ (blockNum $-$ adBlockNum)

37 if  _$\textit{diff}\mod A.\delta_{\rm{bid}}=0$_ then

38 newLowerPrice
$\leftarrow\textit{A.stPrice}-(\textit{diff}/A.\delta_{\rm{bid}})\times
A.\Delta_{\rm{bid}}$

39 notify user about newLowerPrice

Algorithm 4 Block processing by consumer $n$

1

Input: block $B$

2

3func  _processBlockByProposer_ :

4

5 foreach  _expiration for an item advertisement $A$ due to $B$ reaching
$A.\delta_{\textrm{sale}}$ or $A.\delta_{\textrm{reveal}}$ or
$A.\delta_{\textrm{eval}}$_ do

6

7 if  _(expiration is sale expiration) $\land$ ((A.revFlag is true) $\lor$
(A.evalCom is defined))_ then

8

9 continue

/* Postpone the item assignment for trades that defined revelation expiration
or evaluation expiration */

10

11 adBlock $\leftarrow$ block in the ledger s.t. $A\in\textit{adBlock}$

12

13 adBids $\leftarrow\\{\textit{bid}\,|(\textit{bid}$ is for $A$) $\land$ (bid
$\in$ a block stored in the ledger between adBlock and $B$) }

14

15 wBid $\leftarrow$ selectWinningBid(A, adBids)

16 revTx $\leftarrow$ $\perp$

17 txAssignExtraFlag $\leftarrow$ true

18

19 if  _expiration is revelation expiration_ then

20

21 endSaleBlock $\leftarrow$ block stored in the ledger at position adBlock
position + $A.\delta_{\rm{sale}}$

22

23 revTx $\leftarrow$ revelation Tx with resPrice s.t. ((Tx is for $A$)
$\land$ (Tx $\in$ a block stored between endSaleBlock and $B$))

24 if  _( wBid = none) $\lor$ (revTx = $\perp$) $\lor$ (wBid.P $<$
revTx.resPrice)_ then

25

26 txAssignExtraFlag $\leftarrow$ false

27

28 if  _(wBid $\neq$ none) $\land$ (txAssignExtraFlag = true)_ then

29

30 tx $\leftarrow$ create a tx assigning A.tItem to wBid

31

32 else

33 tx $\leftarrow$ create a “no assignment” tx

34 blockchain.addTxToPropBlock(tx)

/* In practice, the solution has to take into account limited block space and
overflows */

35 resolveMoneyFlow(A, adBids, wBid, revTx)

36

Algorithm 5 Block processing by block proposer $n$

##  7 Parameters and their use in algorithms

Our framework supports configurability at both application and system level.
System level parameters were briefly described in the background on blockchain
in Section 2.2. The use case developer needs to configure the framework w.r.t.
system-level parameters (the blockchain type, consensus protocol, and
transaction pruning) at the deployment time rather than on a per-item basis.
Our framework can function atop permissioned or permissionless blockchain,
however a specific use case may only be suitable for one. In permissioned
blockchain, real entity identities are used. In the case of permissionless
blockchain, identities are replaced by pseudonymous public keys. We now focus
on marketplace-level parameters.

###  7.1 Trade type, bid evaluation and matching

Table 1 shows the list of parameters for three events handled by the
framework: item advertisement request, bid request and block inclusion. The
most salient parameters of an item advertisement request are the trading item
tItem, sale duration $\delta_{\rm sale}$ measured in the number of blocks, and
the trade type tType. The framework is extensible, however it explicitly
supports the trade types of English auction, Dutch auction, committee-based
evaluation and ranking, committee-based evaluation and custom objective
ranking and custom objective evaluation and ranking. Note that auctions such
as English and Dutch can be regarded as instances of objective evaluation and
ranking due to the algorithmic selection of the winning bid, according to the
deterministic and well-known matching rules. However, custom objective
evaluation and ranking is a broader category, and custom policies can be
implemented as pluggable algorithms by the use case developer. Algorithm 6
shows the selection process of the winning bid for the listed trade types.

The English auction has a fixed duration $\delta_{\rm sale}$ and a starting
price stPrice. Consumer submits bids, which must observe a minimum increment
constraint $\Delta_{\rm bid}$ in order to be considered valid. Every higher
bid starts a new bidding window. In absence of real time, it is possible to
submit bids with the same payment P in parallel, which may result in a single
bidding window with multiple equal bids. The bidding phase stops due to the
current block reaching the sale expiration, as described in Section 6.2. At
that point the item becomes ready for matching. The winning bid is chosen
pseudo-randomly among the bids of the last bidding window, as motivated in the
challenges in Section 5. If the supplier establishes a reserve price by
setting revFlag to true and including the resPHash in the advertisement, the
selected bid has to be higher than the reserve price. If the supplier fails to
include the revelation of the reserve price within $\delta_{\rm reveal}$
blocks from the advertisement, the item is not assigned and its deposit is
kept by the block proposer as a fee. Similarly, if the selected winning bid is
lower than the reserve price the item is not assigned. However, in the latter
case all the deposits and payments are returned to the respective owners, with
the exception of the transaction inclusion fee, which is always kept by the
block proposers.

Dutch auctions begin with a high stPrice in the item advertisement. The price
is periodically decreased, once every $\delta_{\rm bid}$ blocks, which defines
a window of fixed price. The decrease is by a fixed amount defined by
$\Delta_{bid}$. Within each window, consumers may bid for the item at the
current price. If the window is empty of bids, the next window with a
decreased price starts, unless the reserve price (if defined) is reached. In
that case the auction stops without item assignment. On the other hand, if
there are one or more bids in the current window, the item becomes ready for
matching. In the matching, one of the bids is pseudorandomly selected as the
winner, similarly to the English auction.

1

2

Input: A, adBids

Output: bid

3

4

5func  _selectWinningBid_ :

6

7 if  _adBids $=\emptyset$_ then

8 return none

9 adBlock $\leftarrow$ block in the ledger s.t. $A$ $\in$ adBlock

10

11 switch  _A.tType_ do

12 case  _english auction_ do

13 highestPrice
$\leftarrow\textit{max}_{\textit{bid}\in\textit{adBids}}|\textit{bid}.P|$

14 candidateWinBids
$\leftarrow\\{\textit{bid}\,|\textit{bid}\in\textit{adBids}\land|\textit{bid}.P|=\textit{highestPrice}\\}$

15 wBid $\leftarrow$ select pseudorandom bid $\in$ candidateWinBids

16

17 case  _auction_ do

18

19 $\textit{wBid}\\!\leftarrow$ select pseudorandom bid $\in$ adBids

20

21 case  _committee-based eval and ranking_ do

22

23 endEvalBlock $\leftarrow$ block stored in the ledger at position adBlock
position $+\,A.\delta_{\rm{eval}}$

24 evTx $\leftarrow$ bid eval. Tx with comDecision s.t. ((Tx is for $A$)
$\land$ (Tx $\in$ a block between adBlock and endEvalBlock))

25 if  _evTx = none_ then

// apply marketplace policy

26 wBid $\leftarrow$ none

27

28 wBid $\leftarrow$ evTx.comDecision

29

30 case  _committee-based eval and custom objective ranking_ do

31

32 endEvalBlock $\leftarrow$ block stored in the ledger at position adBlock
position $+\,A.\delta_{\rm{eval}}$

33 evSet $\leftarrow$ {evTx $|$ (evTx is a bid eval. with evScore for $A$)
$\land$ (evTx $\in$ a block between adBlock and endEvalBlock) }

34 if  _$|$ evSet$|$ is insufficient_ then

// apply marketplace policy

35 return none

36 bidScores
$\leftarrow\\{\textit{evTx.evScore}\,|\textit{evTx}\in\textit{evSet}\\}$

37 wScore $\leftarrow$ customObjRanking(bidScores)

38

39 wBid $\leftarrow$ select pseudorandom bid $\in$ {b $|$ b
$\in\\!\textit{adBids}\land\\!\textit{wScore}=\\!\textit{customObjEval}(\textit{b})\\}$

40

41 case  _custom objective eval and ranking_ do

42 bidScores $\leftarrow\emptyset$

43 foreach  _bid $\in$ adBids_ do

44 bidScore $\leftarrow$ customObjEval(bid)

45 bidScores.add(bidScore)

46 wScore $\leftarrow$ customObjRanking(bidScores)

47

48 wBid $\leftarrow$ select pseudorandom bid $\in$ {b $|$ b
$\in\\!\textit{adBids}\land\\!\textit{wScore}=\\!\textit{customObjEval}(\textit{b})\\}$

49return wBid

Algorithm 6 Selection of the winning bid

###  7.2 Additional parameters

Beside the evaluation and matching, the framework supports additional
marketplace-level parameters.

Trading item and metadata — The item tItem is the object of the trade.
Metadata is any information that describes the item and possibly attracts
interested consumers. Its format is specific to the use case.

Selection of the evaluation committee — The evaluation committee evalCom is a
list of identities authorized to evaluate the bids. The simplest approach, and
the one adopted by the framework, is to let the supplier provide such a list.
In principle however, different pseudo-random selection algorithms can be used
to select the evaluation committee members from a superset of designated
nodes. The committee must submit evaluations and ranking within the duration
determined by $\delta_{\rm eval}$. If the committee does not provide all
required information by the expiration, the marketplace applies the relevant
policy in order to determine the outcome of matching, potential reduction in
the committee fee, and compensation to consumers whose bids were not
sufficiently evaluated.

Money and item flow — In the common case, money flows from the consumer to
supplier. However there are some exceptions, for instance in the case of
reverse auctions and contests. Therefore, the framework supports payments $P$
done by consumers or suppliers. Similarly, deposits $D$ are included in bids
or item advertisements. In practice, deposits are treated as locked funds that
cannot be used during the locking period. Upon successful item assignment, the
payment is transferred to the other party either directly or via an escrow (if
an escrow is used). Similarly, the deposit is unlocked either immediately by
the platform or by the escrow at a later point. Algorithm 7 shows the
resolution of the money flow in the framework.

1

Input: A, adBids, wBid, revTx

2

3

4func  _resolveMoneyFlow_ :

5

6 if  _A.P is defined_ then

7 if  _wBid $\neq$ none_ then

8 paymTx $\leftarrow$ create a tx that transfers A.P to the sender of wBid
(electronic trade) or via the escrow (physical goods)

9

10 else

11 paymTx $\leftarrow$ create a tx that unlocks A.P

12

13 blockchain.addTxToPropBlock(paymTx)

14

15 if  _( A.D is defined $\land$ A.revFlag is false) $\lor$ (A.D is defined
$\land$ A.revFlag is true $\land$ revTx $\neq$ $\perp$)_ then

/* The supplier loses the deposit if revTx is not included in time */

16

17 depTx $\leftarrow$ create a tx that unlocks A.D

blockchain.addTxToPropBlock(depTx) /* If the assignment is present and escrow
is used, the escrow will unlock A.D after the trade is completed */

18

19 foreach  _bid $\in$ adBids_ do

20

21 if  _bid.P is defined_ then

22 if  _bid is not wBid_ then

23 paymTx $\leftarrow$ create a tx unlocking bid.P

24 else

25 paymTx $\leftarrow$ create a transaction that transfers bid.P to the
supplier of $A$ or via the escrow

26 blockchain.addTxToPropBlock(paymTx)

27 if  _bid.D is defined_ then

28 depTx $\leftarrow$ create a tx that unlocks bid.D

blockchain.addTxToPropBlock(depTx) /* See comment in line 7 */

29

Algorithm 7 Money flow management

Duration and time — The framework introduces a number of different duration
parameters: $\delta_{\rm sale}$, $\delta_{\rm bid}$, $\delta_{\rm reveal}$ and
$\delta_{\rm eval}$ for placing all the bids, placing bids for a given price,
revelation of secret information by the supplier, and committee evaluation,
respectively. As explained in Section 5, durations are measured in the number
of blocks rather than actual time. The duration parameters is either set upon
item advertisement or fixed upon marketplace deployment.

###  7.3 Algorithms for handling new blocks

We now describe how suppliers, consumers and block proposers act upon the
reception of a new block is described in the algorithms. In Algorithm 3,
suppliers are notified about the assignments of their own advertisements. If
the trade requires disclosure of information such as the reserve price, it is
done upon sale expiration. Algorithm 4 defines a list of advertisements the
consumer is interested in and notifies the user in case of assignments.
Additionally, if the bidding period has not expired yet, the user is notified
about the highest bid value in English auctions (line 4). All bids placed
during a Dutch auction will have the same value. We notify the user about the
value of one such bid in line 4. In the absence of bids, the user is notified
every time the price is lowered (lines 4 to 4).

The reception of a block by the block proposer is handled as shown in
Algorithm 5. Every block proposer maintains a list of unexpired trades and a
counter for each trade. The counter starts from the value of the corresponding
$\delta$ parameter. It is decremented upon new block inclusion. Whenever it
reaches zero, an expiration event for the corresponding item advertisement is
triggered. Every trade undergoes either one or two phases. The first phase
starts with the advertisement and ends after $\delta_{\rm sale}$ blocks. The
second phase is optional and takes place when either the revelation (revFlag
is true) or the evaluation (evalCom is defined) are employed, which are
mutually exclusive within the same trade. The winning bid is selected in line
5. With the support of an extra flag we check in line 5 if there is a winning
bid higher than the reserve price and if the revelation transaction has been
included. Based on this, the block proposer either creates a transaction
assigning the item to the proposer of the winning bid, or a transaction
signifying the absence of assignment. Algorithm results in a number of
transactions being added to the pool of outstanding transactions by calling
addTxToPropBlock. Normally these transactions will be added to the next block
proposed by the block proposer. A more involved algorithm is employed when
some transactions are excluded from the next block because of the block size
limitation; we do not present the detail because of space constraints.

##  8 Sketching the correctness of the solution

The proposed framework addresses all marketplace properties presented in
Section 3, except for the legal and regulatory system property, which must be
handled by means other than a technological solution. Generality and
configurability are due to the framework’s ability to support a range of
configuration parameters and use cases, as illustrated in Sections 7 and 9.
The properties of distributed and blockchain-based marketplaces described in
Sections 3.3 and 3.4 are acquired by construction. We now focus on the
properties of electronic marketplaces.

The proposed solution satisfies the properties of liveness and fairness of
both trade and matching. Fairness of matching can be proven by contradiction
for each of the trade type and matching policies. For example, a bid selected
as winning in the English auction can never be lower than another bid. In
absence of significant collusion, which is unlikely in the blockchain-based
marketplace model, matching in the contest model is fair under the assumption
that the decision of the evaluation committee is honest. Fairness of trade is
ensured by a combination of the deposit mechanism, escrow entity, and legal
obligations, though the guarantee might only be probabilistic in some cases.

The solution provides liveness if the entities correctly follow the protocol
and failures/attacks do not prevent liveness of the underlying blockchain
system. It can be shown for each price discovery and matching policy that the
bidding protocol terminates under these assumptions and that an item
assignment transaction is initiated if there is a matching bid. Besides,
deposits are also returned, if previously placed.

The proposed system is resilient to, e.g., DoS attacks and rational behavior.
Injection of spurious transactions is disincentivized by fees. Rational
behavior of consumers and suppliers is related to the fairness of trade, as
described above. Block proposers and evaluation committee members are
encouraged to follow the protocol by a combination of fees, blockchain
transparency, and potential legal actions.

##  9 Supported use cases and limitations

To demonstrate the generality of our framework, we present three supported use
cases: an auction of physical goods, a logo design contest, and a job posting.
While we have performed a similar design analysis for a real estate
marketplace and the assignment process in scientific peer reviewing, we focus
on the three selected use cases because of their popularity and significantly
diverging requirements. For each use case, we describe the domain, sketch the
requirements and roles, and envisioned parameter configuration at the
application and system level.

###  9.1 Auction of physical goods

The first use case is an online marketplace where multiple buyers and sellers
trade items, in a fashion similar to eBay. The marketplace-level parameters
are as follows.

Trading item and metadata — The tItem is generic physical goods, for instance
a hardcopy book or a domestic appliance. Metadata may include item condition,
shipping information and return policies.

Trade type — The marketplace runs instances of English auctions where
suppliers decide on a per-item basis whether to set the revFlag parameter and
the value of the reserve price. Suppliers independently set a starting price
stPrice and a minimum increment $\Delta_{\rm bid}$ for the raising bids.
Presence of $\Delta_{\rm bid}$ reduces the number of bids and thus,
transactions.

Bid evaluation and matching — Bid evaluation is absent since the bids can be
objectively evaluated based on their proposed payment. The matching is
objective and implemented according to the the English auction, as shown in
Algorithm 6 in lines 6 to 6.

Money and item flow — The item advertisement includes a fee for the block
proposer, a fee for the escrow, and a deposit $D$. The bid includes a fee for
the block proposer and escrow, and a payment P. Upon the assignment inclusion
in the ledger, the tItem is ready to be shipped to the consumer that placed
the winning bid. The shipment is monitored by the escrow. As part of the
trade, $D$ is unlocked and $P$ is transferred to the supplier. For losing
bids, on the other hand, the deposits and payments are immediately returned to
the respective owners.

Duration and time — Auctions on eBay typically last from one to ten days,
which corresponds to roughly a few hundreds blocks at Bitcoin’s proposal rate.
Therefore $\delta_{\rm sale}$ assumes a value in that range. The revelation
duration $\delta_{\rm reveal}$ is set to a small number of blocks, which
should provide enough time for the supplier to broadcast the revelation
transaction. We do not show it in the pseudo-code, however $\delta_{\rm bid}$
may be used as an optimization for English auctions, to trigger the end of
bidding before $\delta_{\rm sale}$ expires. However, the selection of the
winning bid in lines 6 to 6 in Algorithm 6 remains unaltered. On the other
hand $\delta_{\rm eval}$ is not defined for this use case.

Trading process — The trade itself happens through an escrow as described in
Section 6.3.

Regarding system-level parameters, the marketplace is implemented as the
application layer atop a permissionless blockchain such as Ethereum, allowing
validators to freely join and leave. Consensus protocol must support a certain
transaction rate as well as a number of concurrent active users. The
processing at the marketplace layer is lightweight so that the blockchain
consensus protocol may become a bottleneck. For example, Ethereum allows
support of roughly up to 20 transactions per seconds [17]. The participants,
and most importantly the supplier need to consider the marketplace throughput
when establishing the trade duration. The marketplace prunes transactions
belonging to correctly assigned trades that are older than an age established
at marketplace deployment time.

###  9.2 Logo design contest

The second use case illustrates how the framework supports subjective
evaluation when required by the trade type. We describe a contest for the
selection of a logo i.e. a graphical representation for business purposes. The
artistic quality assessment for a logo design contest is an important yet non-
trivial procedure. Therefore, it requires the employment of an evaluation
committee. The supplier starts by advertising the contest on the marketplace,
which prompts bid submissions. Evaluation scores are multi-dimensional and
weighted according to the objective ranking algorithm. The marketplace-level
parameters are as follows.

Trading item and metadata — The tItem is the formal announcement of the
contest. Metadata includes submission guidelines describing the features the
committee is going to evaluate, such as logo composition, choice of colors,
novelty. Metadata include additional information about submission format,
desired application domain and copyright concession.

Trade type — The trade type is committee-based evaluation and custom objective
ranking. The artistic quality of the submission is evaluated by a human
committee, however the ranking is implemented as a custom objective function
by the use case developer. This increases the objectivity of the matching and
improves transparency by decoupling evaluation and ranking.

Bid evaluation and matching — Evaluation criteria and features are specified
in the metadata of the item advertisement. The committee submits one
transaction per bid containing the numerical scores of every evaluated
feature. The scores are processed by the block proposers as shown in Algorithm
6 in lines 6 to 6. Upon evaluation expiration, block proposers compute the
matching. The logo with the highest score is selected as the winner of the
contest, while possible ties are resolved with a pseudo-random function.

Selection of the evaluation committee — The committee members authorized to
evaluate the bids are selected during the item advertisement. Only the
authorized public keys, in case of permissionless blockchain, or real
identities, for permissioned, may propose evaluations.

Money and item flow — In this case, the logo is provided as content inside the
bid. Money follows the reverse path, from supplier to consumer. The payment
value $|P|$ is decided by the supplier in the item advertisement; there is no
payment in the bid. $|P|$ remains constant for the duration of the trade and
is transferred to the winner in the item assignment. Deposits $D$ may be
locked for both supplier and consumers, to prevent fake contests and
submissions. The exact structure of the deposits is subject of economic
research.

Duration and time — A plausible duration for the logo submission $\delta_{\rm
sale}$ is a couple of weeks which, at Bitcoin’s proposal rate, would span an
interval centered at about 2000 blocks. The committee needs several week to
evaluate the submissions, which would translate to several thousand blocks.
Parameters $\delta_{\rm reveal}$ and $\delta_{\rm bid}$ are not defined for
the logo contest.

Trading process — The trade is purely electronic. Upon the item assignment
transaction, the ownership of the winning logo is transferred to the supplier
while the payment is transferred to the winning consumer.

At the system level, the logo contest marketplace is based on a permissioned
blockchain, such as Hyperledger Fabric. Validators, suppliers, consumers and
all the participating entities are authenticated. Update permission, i.e., the
permission to broadcast new transactions is restricted to authorized members,
but for the sake of transparency, no constraint is imposed on reading the
ledger. The expected rate of bid submissions is low, therefore the choice for
the consensus protocol is driven, in this case, by the number of authenticated
nodes. A small number of nodes, in the order of a few dozens, allows the use
of BFT protocols such as PBFT [18] or BFT-SMART [19]. Contests older than a
few years and not subject to legal litigation can be pruned to free the
metadata storage.

###  9.3 Job posting

The last use case has been selected to showcase the framework support for a
less traditional marketplace application: a hiring process conducted for a
joint project between collaborating companies, each of them having limited
trust in the others. The open position is advertised on a blockchain-based
marketplace. The candidates go through the off-chain interview process, and
the final ranking is registered on the blockchain. The hiring choice is
securely stored for auditing and legal purposes.

Trading item and metadata — The tItem is the job position. Metadata includes
information provided by the hiring companies and general requirements for the
candidates. An example of the former is contract information, annual salary
and benefits.

Trade type — The job marketplace adopts committee-based evaluation and ranking
due to the acknowledged complexity of selecting the best candidate for a job
position. The high number of features that are subjectively evaluated, and
their non-linear combinations make the objective ranking unsuited for the use
case.

Bid evaluation and matching — Applicants bid by submitting publicly available
information about their professional career and experiences. The evaluation
takes place off-chain. Afterwards, the committee signs a single transaction
containing the evaluation and ranking of the valid applications and,
optionally, details on individual evaluation motivating the ranking. The
matching is simple and deterministic, based on the decision of the committee,
as showed in Algorithm 6 in lines 6 to 6.

Selection of the evaluation committee — The evaluation committee evalCom is
selected by the supplier in the item advertisement.

Money and item flow — The item assignment declares the winner of the job
posting, however it does not trigger a money exchange, which instead happens
off-chain. On-chain currency is used, on the other hand, to pay the fee to the
evaluation committee. Deposits $D$ may be required for supplier and consumers,
to prevent fake job posting and applications.

Duration and time — The job advertisement is active and validators accept bids
for $\delta_{\rm sale}$ number of blocks. A plausible duration for the
advertisement is several weeks. After the expiration of the evaluation period
$\delta_{\rm eval}$, the job position is either assigned or not, based on the
evaluation of the committee. This use case does not define $\delta_{\rm bid}$
and $\delta_{\rm reveal}$.

Trading process — The “trade” consists in signing an agreement between the
supplier (which will be the employer) and the winning consumer (which will be
the employee). The trade does not involve monetary transactions.

We expect the job posting marketplace to receive a limited number of
transactions per second. However, due to the sensitive nature of the managed
information, it would need to have a fine grained control on the data
dissemination. Therefore we envision the marketplace supporting job posting
advertisements to be based on a permissioned blockchain, with additional
features to ensure confidentiality. The participating entities are
authenticated. The choice of consensus protocol is similar to that of the logo
contest use case. In the committee-based evaluation and ranking, every correct
trade has exactly one bid evaluation and ranking transaction. Therefore,
considering the small storage requirement for the evaluations and the
assignments, pruning is not implemented.

###  9.4 Inherent limitations of blockchain-based marketplaces

Consistency maintenance over geographically distributed nodes introduces
sensible delays in transactions submission and confirmation, therefore posing
a limit on use cases that require semi real-time execution. Blockchain-based
marketplaces are thus not suitable for some application scenarios such as
high-frequency trading [20] or real-time bidding strategies.

##  10 Related Work

While there exists a significant body of research on marketplaces, they mostly
focus on economic aspects and application study. An early work [21] (published
before blockchains were conceptualized), analyzes the requirements and
proposes ideas for implementing a modular electronic marketplace.

There are a few recent works which explore the idea of blockchain-based
marketplaces. One of the first works describes advantages of using blockchains
for electronic marketplaces for various trading items [7]. Similarly [6]
proposes a decentralized marketplace based on Ethereum albeit the focus is on
services as the traded items. In [4, 3], the authors propose a marketplace
based on the Ethereum blockchain and analyze gas consumption for the smart
contract execution. Blockchain-based techniques for secure data exchange and
monetization of the data is proposed in [5] and in [22] respectively. A
blockchain-based platform for the transfer of car ownership is studied in [23]
with a focus on software engineering aspects dictated by the provided
specifications. However, these works do not consider the challenges and
limitations of blockchain-based approaches, propose concrete algorithms, or
explore multiple trade types. To the best of our knowledge, our work is the
first to systematically consider these challenges and address them in detailed
algorithms for the matching functionality of marketplaces over blockchain.
Moreover, our proposed platform is generic: it supports a significant variety
of trade types through an extensive list of configurable parameters and
callbacks implemented by the use case developer.

In terms of commercial solutions, OpenBazaar [24], and more recently Origami
[25], provide a decentralized infrastructure for marketplaces. The latter is
implemented on top of Ethereum, therefore adopting their token standard. The
design of both solutions focuses on the trading procedure as opposed to
matching. For example, the support is limited to a fixed price trade type to
the best of our knowledge.

##  11 Conclusion and future work

In this paper, we proposed a generic and configurable framework for
blockchain-based marketplaces. The use of blockchain endows the marketplace
the inherent properties of integrity, authenticity, and transparency. However,
the decentralized nature of blockchain limits a few applications, most notably
the ones involving high-frequency and real-time bidding. The deployment of
well studied price discovery and matching mechanisms like auctions require
careful consideration of the characteristics of blockchain systems. The
extension of auctions, among other mechanisms, for blockchains is therefore
non-trivial. The proposed framework supports various price discovery and
matching policies. It includes a systematic approach to the mechanisms for
item advertisement, bidding and bid evaluation, and incentives for the
involved parties towards a correct behavior.

We also presented concrete event-based algorithms constituting our solution
framework. Finally, to illustrate the configurability of the framework both at
the application and blockchain level, we presented three different use cases
with diverging requirements.

We identify the following directions for future work:

Privacy — Addressing the privacy of the buyers and sellers and compliance to
data protection regulations such as GDPR, especially for the use cases such as
“Job posting” is essential for decentralized marketplaces. The blockchain-
based solution framework presented in this paper provides essential building
blocks which may be used for implementing privacy features in the future work.

Fee structure — Correct incentives to prevent misuse of the marketplace by the
participating entities such as block proposers, committees, etc. require a
detailed economic study to choose a fair fee and deposits structure. Although
the framework partly addresses them, a thorough analysis is beyond the scope
of this paper and left for future work.

Terms-of-service — Terms-of-service support agreements between the buyers,
sellers, and organizations deploying the blockchain.

Reputation system — In any marketplace, the consumers prefer to buy from
reputed suppliers. Permissioned blockchain-based marketplaces may include such
reputation systems.

## References

  * [1] EcommerceDB., https://ecommercedb.com/en/ranking/ww/all, accessed: 11-2019.
  * [2] Y. Chang, K. Lin, C. Shen, Blockchain Technology for e-Marketplace, IEEE PerCom Workshop (2019).
  * [3] O. R. Kabi, V. N. Franqueira, Blockchain-based distributed marketplace, in: Lecture Notes in Business Information Processing, Vol. 339, 2019.  doi:10.1007/978-3-030-04849-5{\\_}17.
  * [4] V. P. Ranganthan, R. Dantu, A. Paul, P. Mears, K. Morozov, A decentralized marketplace application on the ethereum blockchain, in: IEEE CIC, 2018.  doi:10.1109/CIC.2018.00023.
  * [5] P. Banerjee, S. Ruj, Blockchain enabled data marketplace-design and challenges, arXiv preprint arXiv:1811.11462 (2018).
  * [6] M. Klems, J. Eberhardt, S. Tai, S. Härtlein, S. Buchholz, A. Tidjani, Trustless intermediation in blockchain-based decentralized service marketplaces, in: Lecture Notes in Computer Science, Vol. 10601, 2017.
  * [7] H. Subramanian, Decentralized blockchain-based electronic marketplaces, CACM 61 (1) (2018).  doi:10.1145/3158333.
URL https://doi.org/10.1145/3158333

  * [8] Y. Bakos, The emerging role of electronic marketplaces on the Internet, CACM 41 (8) (1998).  doi:10.1145/280324.280330.
  * [9] P. McAfee, J. McMillan, Auctions and Bidding, in: The New Palgrave Dictionary of Economics, 1987.  doi:10.1057/978-1-349-95189-5{\\_}340.
  * [10] Hyperledger Fabric., https://hyperledger-fabric.readthedocs.io/, accessed: 11-2019.
  * [11] Gavin Wood. Ethereum: A secure decentralised generalised transaction ledger., https://gavwood.com/paper.pdf, accessed: 11-2019.
  * [12] A. Bessani, E. Alchieri, J. Sousa, A. Oliveira, F. Pedone, From byzantine replication to blockchain: Consensus is only the beginning, arXiv preprint arXiv:2004.14527 (2020).
  * [13] M. Vukolić, The quest for scalable blockchain fabric: Proof-of-work vs. bft replication, in: Open Problems in Network Security, Springer International Publishing, 2016.
  * [14] eBay., https://www.ebay.com/, accessed: 4-2020.
  * [15] Y. Gilad, R. Hemo, S. Micali, G. Vlachos, N. Zeldovich, Algorand: Scaling byzantine agreements for cryptocurrencies, in: SOSP, 2017.
  * [16] S. Goldfeder, J. Bonneau, R. Gennaro, A. Narayanan, Escrow protocols for cryptocurrencies: How to buy physical goods using bitcoin, in: International Conference on Financial Cryptography and Data Security, 2017.
  * [17] A. Chauhan, O. P. Malviya, M. Verma, T. S. Mor, Blockchain and scalability, in: 2018 IEEE International Conference on Software Quality, Reliability and Security Companion (QRS-C), 2018, pp. 122–128.
  * [18] M. Castro, B. Liskov, et al., Practical byzantine fault tolerance, in: OSDI, Vol. 99, 1999.
  * [19] A. Bessani, J. Sousa, E. E. P. Alchieri, State machine replication for the masses with bft-smart, in: IEEE/IFIP International Conference on Dependable Systems and Networks, 2014.
  * [20] O. Kaya, J. Schildbach, D. B. Ag, High-frequency trading, Automated trader magazine 41 (2016).
  * [21] A. W. Röhm, G. Pernul, COPS: A model and infrastructure for secure and fair electronic markets, Decision Support Systems 29 (4) (2000).  doi:10.1016/S0167-9236(00)00082-8.
  * [22] M. Travizano, C. Sarraute, G. Ajzenman, M. Minnoni, Wibson: A decentralized data marketplace, arXiv preprint arXiv:1812.09966 (2018).
  * [23] B. Notheisen, J. B. Cholewa, A. P. Shanmugam, Trading Real-World Assets on Blockchain, Business & Information Systems Engineering 59 (6) (2017) 425–440.  doi:10.1007/s12599-017-0499-8.
  * [24] OpenBazaar., https://openbazaar.org/, accessed: 11-2019.
  * [25] Origami Network., https://ori.network/wp-content/uploads/2017/11/Origami-Network-Whitepaper-0.1-1.pdf/, accessed: 5-2020.