ABCrowd: An Auction Mechanism on Blockchain for Spatial Crowdsourcing

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.2965897, IEEE Access
Date of publication xxxx 00, 0000, date of current version xxxx 00, 0000.
Digital Object Identifier 10.1109/ACCESS.2017.DOI
ABCrowd: An Auction Mechanism on
Blockchain for Spatial Crowdsourcing
MAHA KADADHA1
, (Member, IEEE), RABEB MIZOUNI1,2
, SHAKTI SINGH1,2
, (Member, IEEE),
HADI OTROK1,2
, (Senior Member, IEEE), and ANIS OUALI3
1
Electrical and Computer Engineering Department, Khalifa University of Science and Technology, Abu Dhabi, UAE
2
Center on Cyber-Physical Systems, Khalifa University of Science and Technology, UAE
3
Emirates ICT Innovation Center (EBTIC), Abu Dhabi, UAE
Corresponding author: Maha Kadadha (e-mail: maha.kadadha@ku.ac.ae).
This work was supported by the Khalifa University Internal Research Fund (KUIRF Level 2) under Project 8474000012.
ABSTRACT In this paper, a fully distributed auction-blockchain-based crowdsourcing framework is
proposed- ABCrowd. In a typical crowdsourcing framework, independent workers compete to be allocated
requesters’ tasks. These workers advertise their costs to the centralized platform, which then decides the
final allocation of tasks. While performing the allocation, centralized platforms face two main challenges:
1) how to ensure trusted execution for the allocation of tasks, and 2) how to motivate workers to declare their
truthful costs. To address these challenges, ABCrowd proposes to run the crowdsourcing platform entirely
on Ethereum Blockchain while incorporating auctions. Blockchain and smart contracts guarantee trusted
execution for the allocation through autonomous and transparent on-Chain execution. ABCrowd uses the
Repeated-Single-Minded Bidder (R-SMB) auction mechanism, which motivates workers to bid truthfully
before allocating them and calculating their payments. R-SMB is an approximation of the optimized off-
Chain Vickrey-Clarke-Groves (VCG) mechanism in terms of maximized profit. It entails repeating the
Single-Minded Bidder (SMB) auction mechanism to meet the allocation requirement of crowdsourcing
applications. ABCrowd is implemented and evaluated using Solidity on a private Ethereum Blockchain,
where a real publicly available dataset is used. The proposed on-Chain R-SMB auction mechanism
is compared to the off-Chain VCG mechanism, where the results show that R-SMB provides similar
performance to VCG in terms of the average number of allocated tasks. Furthermore, R-SMB outperforms
VCG in workers’ travelled distance and requesters’ costs, at a low execution cost.
INDEX TERMS Crowdsourcing, Blockchain, Smart Contracts, Auction
I. INTRODUCTION
Billions of users worldwide currently own smart phones
[1] that are packed with several sensors such as camera,
microphone, accelerometer, etc. [2]. This has motivated the
migration from traditional data collection methods to crowd -
sensing or -sourcing frameworks [3]. In crowdsensing/ sourc-
ing frameworks, requesters advertise the tasks that should be
fulfilled by workers through payment to compensate them
for their services. These tasks can be spatial in their nature
(such as environmental monitoring) or non-spatial (such as
surveys). In typical crowdsensing activity, the users’ interac-
tions, allocation of tasks and calculation of workers’ payment
are governed by a centralized platform.
However, crowdsensing centralized platforms are facing
many challenges, namely we cite: 1) How to motivate work-
ers to share their truthful costs with the framework to maxi-
mize their profit? 2) Having a limited budget per task, how to
determine optimized payments competing to fulfill the same
tasks? 3) How to guarantee trusted interactions among users
and trusted execution by the centralized platform?
Truthful auction mechanisms such as second-price auc-
tion and Vickrey-Clarke-Groves (VCG) mechanism [4] are
designed to motivate bidders to share truthful costs. These
auctions allow bidders (workers) to declare their bids (costs)
for the auctioned items (tasks). Then, an auctioneer (central-
ized platform) can determine the best allocation of items to
bidders. Truthful auctions guarantee that a bidder’s profit is
maximized when sharing truthful costs with the auctioneer
[5]. Auctions also optimize the calculated payments by con-
sidering the social contribution of workers. In other terms,
while workers’ allocation depends on their own bids, their
payments depend on their contribution to the auction.
VOLUME 4, 2016 1

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS
Recently, the combined use of auctions and blockchain
has been seen for blockchain resource management [6], [7]
and in applications such as economy trading [8]–[11], and
crowdsensing [12]–[16]. In these works, the auctioneer re-
sponsible for collecting the bids and executing the auction
is a centralized platform or a trusted third-party. A service
fee is enforced by these auctioneers which increases the cost
of completion for requesters’ tasks. Meanwhile, auctioneers
do not allocate the tasks in a transparent process to either
requesters or workers. As a consequence, the auctioneer can
manipulate the auction’s final allocation and payments in
an untraceable manner due to coalitions formed between
itself and requesters or workers. The major limitation in
these efforts, except [8], is their dependency on an off-
Chain centralized component to run the auction or maintain
privacy. Running auctions off-Chain is mainly due to the
heavy computation of the selected auction and/ or its in-
feasibility due to blockchain’s the limit in transaction size.
Consequently, the research challenge this work tries to
overcome is: How to build a distributed crowdsourcing
framework for spatial tasks, which 1) guarantees users
trusted execution (through blockchain) and 2) ensures work-
ers’ truthfulness (through auctions)? The auction mechanism
should tackle the auction properties while addressing the
crowdsourcing requirements. The framework and auction
mechanism should be feasible for 3) full distributed deploy-
ment on blockchain in a cost-efficient manner for all users.
To answer this challenge, this paper proposes a fully dis-
tributed crowdsourcing framework which implements auc-
tions over blockchain- ABCrowd. The auction motivates the
workers to advertise their truthful costs for highest profit.
Meanwhile, Ethereum blockchain permits trusted execution
of implemented functions and trusted interactions between
requesters and workers in a distributed environment. The
smart contracts running on Ethereum blockchain are used as
a replacement for the centralized platform to run the auction.
FIGURE 1: Proposed Framework: Components and Abstract
Interactions
In this framework, shown in Fig. 1, the designed smart
contract accepts tasks from requesters and saves them until
they are completed. Then, workers query the smart contract
to determine the set of tasks they want to compete on. The
workers initially submit their bids sealed through hashing to
the smart contract. The bid contains the set of tasks they
are interested in and their cost. Sealed-bids prevent other
workers from intentionally overbidding each other. They are
revealed after the bidding time interval expires and the smart
contract verifies the revealed bids compared to the declared
sealed ones. Next, the auction is executed to allocate tasks
and workers, and calculate the corresponding payments.
In order to increase the scalability of the proposed solution
and overcome blockchain maximum transaction size, tasks
are grouped into zones defined by geographical locations.
The auction is then executed for each zone independently. It
allows more workers to participate in the auction compared
to a single auction for all locations.
A modified Single-Minded Bidder (SMB) auction mecha-
nism is used in the framework [17]. It provides an approx-
imation for the social welfare of bidders compared to the
optimized VCG mechanism, where the workers (bidders)
bid for a set of tasks. The selection of this mechanism
is motivated by its computational efficiency which permits
running it on-Chain within the smart contract. However,
SMB does not account for the percentage of allocated tasks
which is of concern in crowdsourcing. That as tasks are
independent, hence each of them needs to be fulfilled. Hence,
SMB is repeated multiple times for workers to re-bid on
remaining tasks; the repeated auction mechanism is referred
to as Repeated-SMB (R-SMB).
ABCrowd is implemented in Solidity [18] and deployed on
a private Ethereum blockchain using a real dataset [19]. The
performance of the proposed on-Chain R-SMB auction is
compared to the off-Chain optimized VCG mechanism since
the core SMB auction mechanism is an approximation of
VCG. The results show that the performance of the proposed
auction mechanism is comparable in terms of number of allo-
cated tasks, while workers’ travelled distance and requesters’
cost are improved for R-SMB.
Our main contributions are summarized as follows:
• Proposing a distributed crowdsourcing framework
which implements auctions over Ethereum blockchain
for trusted execution and truthfulness.
• Designing R-SMB auction mechanism which adopts
and adapts the SMB auction mechanism to increase the
allocation of tasks. R-SMB provides truthfulness, ap-
proximate social welfare and computational efficiency
for on-Chain deployment.
• Demonstrating the feasibility of the on-Chain auction
mechanism and comparing it to the off-Chain VCG
while showing its lower execution cost.
Organization The remainder of this paper is organized
as follows. Section II presents the related work. Section
IV presents the proposed ABCrowd framework; overview,
auction mechanism, smart contract and process. Section V
presents the performance evaluation of the proposed frame-
work and gas cost. Section VI concludes the paper.
II. RELATED WORK
In this section, works that use auctions are described. An
auction, by definition, is a process to where items are bought
and sold according to bids. Sellers advertise items while
buyers propose bids to buy them. Then, the allocation is done
2 VOLUME 4, 2016

based on an auction mechanism. Auction mechanisms can be
classified to different types according to several factors such
as the bid privacy (open vs sealed), the payment function
(first-price vs second-price), and the number of items auc-
tioned; single item vs combinatorial [20]. The related work is
two-fold: First, the use of auction in crowdsourcing, Second,
the integration of auction in blockchain.
A. CROWDSENSING /SOURCING AND AUCTIONS
Auctions were introduced to crowdsensing/ sourcing for task
allocation and payment computation. Truthful auctions are
designed to motivate workers to advertise truthful costs for
maximum profit because of the direct impact of their ad-
vertised costs on the allocation mechanism. Especially that
workers can misreported their costs to affect the worker-task
allocation and the calculated payments.
Proposed auction-based crowd efforts such as [13]–[16]
focus on improving the assignment of tasks and optimizing
workers’ payments. These works consider 3 main actors: 1)
bidders, 2) sellers, and 3) an auctioneer; typically a central-
ized off-Chain platform. In these works, different auction
mechanisms are deployed such as VCG, double auctions,
and max-min. However, all these efforts lack transparency
in the auction execution due to running it on an off-Chain
platform. Hence, they are not necessarily trusted by workers
and coalitions may rise between the different actors.
Furthermore, auctioneers charge requesters a service fee
for running the auction [21]. Scalability rises as an additional
aspect to consider when a single auctioneer is responsible for
running all the auctions. A single auctioneer can also lead
to a denial of service. Lastly, while [13] introduces sealed-
bids by symmetric keys, the other works neglect the impact
of sealed-bids on the engagement of users with the platform.
B. BLOCKCHAIN AND AUCTIONS
Auctions were introduce to blockchain on two frontiers: 1)
Blockchain resource management [6], [7] and 2) Blockchain-
based applications such as finance [8]–[11], and crowd-
sensing [12]. These applications were proposed to address
the management and trust challenges in centralized auc-
tions. Merging blockchain and auction mechanisms guar-
antees both truthfulness (auction) and trust (blockchain).
Trust comes from blockchain’s transparent execution when
running the auction within a smart contract. With smart con-
tracts, the winner of an auction is determined in a verifiable
manner by other users without needing a trusted auctioneer.
On-Chain auctions also reduce a seller’s cost as the service
fees from centralized platform are eliminated and the seller
will only pay for the execution of the auction.
In [6], [7], offline auctions are proposed for blockchain
resource management. They target resource allocation for
edge computing mobile devices utilized in blockchain min-
ing. In [6], an auction mechanism to maximize the utility of
edge service providers is formulated. Alternatively, in [7], a
neural network is utilized to learn the optimal auction for
maximizing the profit. It is worth noting that both models
are not concerned with the privacy of bidders and run on
centralized platforms.
In [8], a collusion-resistant auction is proposed for e-
Auctions. The auction runs fully on blockchain with smart
contracts handling all interactions. The objective is to over-
come collusion when allocating k-items to k-users, all with
the same price. Sealed-bids are generated by workers through
hashing the bid along with a random value. Once the bidding
interval is over, the bid and the random value are revealed
with the smart contract to verify the correctness of the
generated hash and accept the bid before running the auction
mechanism.
In [9], a first-price sealed-bid auction is presented which
partially runs on blockchain for financial applications. Trans-
actions such as bid commit and reveal are logged on-Chain
while a user’s bid is sealed off-Chain through Pedersen’s
commitment scheme [22]. This work proposes off-Chain
winner determination by the auctioneer to maintain the pri-
vacy of losing bids from the transparent blockchain. Nev-
ertheless, zero-knowledge proof [23] is used to verify the
correctness of the submitted winner on-Chain by the auction-
eer. In [10], the same authors further improve their model
by introducing full privacy through utilizing a trusted Intel
enclave hardware to run the auction.
In [11], a Vickrey auction is implement on blockchain for
exchanging storage while maintaining users’ privacy. Users’
privacy is denoted by the sealed-bids which are revealed once
the bidding interval is over. Bids are sealed through bidders’
generated credentials. These credentials are generated by a
collaboration of authorities to prevent centralized manage-
ment for credentials and protect users’ privacy.
In [12], a combinatorial Bayesian incentive compatible
auction mechanism is proposed for crowdsensing on top of
blockchain. The auction is used to minimize the payment of
requesters while guaranteeing a minimum completion prob-
ability for tasks. Smart contracts are utilized to manage the
interaction between users, requesters and workers. Workers’
privacy is maintained through temporary accounts generated
by the Internet Service Provider (ISP). Despite the proper
formulation, the auction is not implemented on blockchain
to verify its feasibility.
C. DISCUSSION
Table 1 presents a summary of the existing auction models
both in crowdsourcing and blockchain. When focusing on
existing auction-based blockchain models, their main limi-
tation is their dependency on an off-Chain platform to run
the auction as they use computationally expensive mecha-
nisms. This defeats the purpose of utilizing the distributed
blockchain to eliminate challenges of centralized platforms.
Hence, making these models vulnerable to problems such
as information disclosure, coalition formation, and untrusted
execution. When focusing on crowdsensing/ sourcing efforts,
there is a lack in blockchain-based models. Especially that
the existing effort [12] does not implemented the proposed
VOLUME 4, 2016 3

TABLE 1: Comparison of Existing Proposed Auction Models
Paper Application on-Chain off-Chain Auction Mechanism Sealed-bid
[6] Blockchain Resource
Management
× (All) Social Welfare Maximization ×
[7] Blockchain Resource
Management
× (All) Social Welfare Maximization ×
[8] e-Auction × Collusion Resistant (Hashing)
[9] Finance (Auction) First-price auction (Peterson Commitment Scheme)
[11] Finance (Credentials and
Auction)
Combinatorial Auction (Encryption)
[12] Crowd Sensing (User Accounts) Combinatorial Auction (ISP)
[13] Crowd Sensing × Bipartite graph matching (Agent)
[14] Crowd Sourcing × Online Double Auction ×
[15] Crowd Sensing × Max-Min & Price-Ranked
Matching
×
[16] Crowd Sourcing × Double Auction ×
Proposed
Model
Crowd Sourcing × R-SMB (Hashing)
auction on-Chain to prove its feasibility and still relies on an
ISP for user privacy.
While [8] proposes a fully distributed and implemented
auction mechanism, it is concerned with mitigating collusion
in the case of multiple items sold with the same price. For
crowdsourcing, other mechanisms need to be explored which
fit the problem of task allocation in a better manner.
III. PROPOSED REPEATED-SINGLE-MINDED BIDDER
(R-SMB) AUCTION MECHANISM
In this section, the proposed Repeated-Single-Minded bidder
(R-SMB) auction mechanism is described. R-SMB is used to
allocate sets of tasks to workers in the proposed framework,
as detailed in this section.
In the literature, multiple auction mechanisms have been
proposed for single item allocation and multiple items al-
location. Vickrey-Clarke-Grooves (VCG) [4] was proposed
as a truthful auction mechanism for allocation of multiple
items. It allocates based on the maximization of the social
welfare of bidders while charging/ paying bidders based on
their social contributions. Unfortunately, VCG is an NP-
hard optimization problem, hence approximations such as the
Single-Minded Bidder (SMB) [17] are proposed.
SMB assumes a bidder is interested in being allocated a
given set of items for a proposed bid or nothing otherwise. It
fulfills the following desired auction properties:
• Truthfulness as each bidder maximizes his/her utility
by bidding truthfully. In SMB, truthfulness is linked to
monotonicity where a worker would remain a winner if
he bids a higher value for a subset of the allocated items.
A critical payment is paid by the winner which reflects
the minimum payment needed to keep him winning.
• Individual rationality as a truth-telling bidder has a non-
negative utility.
• Social efficiency as SMB results in a maximum
√
m
difference from the optimal VCG social welfare, where
m is the size of the set of items bidders bid for.
• Computational efficiency as the mechanism follows a
greedy selection for the winners.
SMB is selected for the proposed distributed framework
since it can be a computationally efficient on-Chain combina-
torial auction mechanism with approximate performance to
VCG in terms of maximum social welfare. In crowdsourcing,
the target of the platform is to allocate a maximum number of
the requesters’ published tasks; a factor that is not taken into
consideration in the SMB auction. Therefore, SMB has been
modified to fulfill this requirement. This modified mecha-
nism is called Repeated-Single-Minded Bidder (R-SMB).
Before presenting the R-SMB auction mechanism, the
metrics of the workers are first described. Let W be the set
of workers and T the set of available sensing tasks. For each
worker i ∈ W and task j ∈ T, we define:
• xi and yi: the x and y coordinates of worker i.
• ri: the maximum radius between worker i and the task
location he or she is willing to bid for.
• Si: the set of tasks worker i is bidding for.
• bi: the bid of worker i for the set of tasks Si.
• xi: a binary value assigned by the auction mechanism to
worker i. xi = 1 means that i is allocated Si, otherwise
xi = 0.
• pi: the critical payment for worker i as calculated by the
auction. pi = 0 when xi = 0, and pi > 0 otherwise.
• xj and yj: the x and y coordinates of the task.
• dij: the distance between the location of worker i to the
location of task j.
• vij: the true cost value worker i estimates for task j.
• bij: the bid of worker i for task j used for bi; bij ≥ vij.
The R-SMB auction mechanism is shown in Algorithm 1.
In each round, workers determine the bids and sets of tasks
they are bidding for to share with the auctioneer, i.e. (bi, Si)
for worker i, as shown in line 3. The bids depend on the
proximity of a worker to the set of tasks he is bidding for,
where a higher bid implies closer workers.
Next, the allocation mechanism, in lines 4 - 9, entails
how allocated workers (Winners) are selected in a greedy
manner to fulfill available tasks. The auction normalizes
the workers’ bids by the square root of the task set size
(bi/ |Si|), as in SMB, implying the rank of a worker’s bid.
4 VOLUME 4, 2016

Then, the ranks of the workers are sorted in a descending
order. Winners are selected starting from the highest ranked
worker and added to the Winners set. Before adding a
winner, his set of tasks is checked to ensure the set does
not intersect with the set of tasks of the previously added
winners. The assigned set of tasks is then removed from the
set of available tasks.
In lines 10 - 22, the payment function is detailed. An allo-
cated worker i is paid the critical payment pi to maintain his
rank. This payment is determined by finding the competing
worker with lower rank who would have been selected if i
did not bid for his/ her set of tasks. Two conditions qualify
a worker to be a competitor as described in the algorithm: 1)
the competing worker’s set of tasks intersects with i’s set of
tasks with at least one task, and 2) the worker’s set of tasks
does not intersect with other existing winners’ sets of tasks.
Consequently, pi for the allocated worker is calculated con-
sidering the competing worker’s rank information according
to line 22.
These steps are repeated multiple times allowing workers
to identify remaining tasks and update their bids and sets
of tasks based on them. Ideally, R-SMB should be repeated
until all tasks are allocated. However each iteration executed
on-Chain entails an execution cost. In order to maintain a
reasonable execution cost, a maximum number of repetition
iterations ar needs to be selected. Consequently, the auction
will be terminated if all tasks are allocated or ar rounds are
repeated.
IV. PROPOSED ABCROWD FRAMEWORK
In this section, ABCrowd, the proposed auction-blockchain-
based crowdsourcing framework, is described. First, an
overview of the framework is presented to understand the
components of ABCrowd deployed on Ethereum. Second, the
mechanism used to group tasks into zones is presented. Third,
the implementation of the framework is illustrated. Lastly, the
general scenario for the framework timeline is described.
A. ABCROWD OVERVIEW
The proposed ABCrowd crowdsourcing framework utilizes
the Ethereum blockchain [24] capabilities for a fully de-
centralized crowdsourcing process. ABCrowd framework is
built completely on Ethereum using smart contracts to over-
come the challenges of centralized and off-Chain execution.
Hence, it provides workers and requesters with execution
transparency and reliability.
Requesters share geo-tagged tasks with the designed smart
contract along with the budgets for the tasks. The smart
contract collects the tasks to allocate them transparently on-
Chain using the proposed R-SMB auction mechanism where
it motivates workers to bid truthfully. However, on-Chain ex-
ecution of R-SMB restricts the number of tasks and workers
the auction can handle during the execution. That is due to
the maximum transaction size by Ethereum. Therefore, the
smart contract uses the tasks’ geo-locations to map them into
pre-defined zones, shown as grid elements in Fig. 2. Further
Algorithm 1 Repeated-Single-Minded Bidders (R-SMB)
ar = maximum auction iterations
n = number of workers
T = set of available tasks
Winners = set of allocated workers
(bi, Si) = bid and set of tasks for worker i
1: for round = 1, . . . , ar && T = φ do
2: determines Si and bi ∀i, ∈ n
3: workers share Si and bi with the auctioneer
% Allocation Mechanism
4: Winners = φ
5: sort{ b1√
|S1|
, b2√
|S2|
, . . . bn√
|Sn|
} in descending order
6: for m = 1, . . . , n do
7: if Sm ∩ (∪w∈W innersSw) == φ then
8: Winners ← Winners ∪ {m}
9: T = T Sm
% Payment Function
10: for i = 1, . . . , n do
11: if i /∈ Winners then
12: pi ← 0
13: else
14: for j = i + 1, . . . , n do
15: if (Si ∩ Sj = φ) then
16: competitor = j
17: for k = 1, . . . , j-1 and k ∈ Winners do
18: if Sj ∩ Sk = φ then
19: competitor = φ
20: break
21: if competitor = φ then
22: pi =
bj ×
√
|Si|
√
|Sj |
details about task zones are given in the following Section
IV-B. Consequently, the R-SMB auction is run individually
for each zone to maintain the feasibility and scalability of the
framework.
Workers view available tasks in the smart contract along
with the tasks’ corresponding zones. The tasks within their
range are identified and the corresponding bid for each task is
calculated. Then, the bid for each set of tasks within a given
zone is calculated. A worker selects the set of tasks in the
zone that maximizes his/her profit. Consequently, the worker
share the set of tasks to bid for, their zone, and the bid (sealed
and revealed) to the smart contract.
After the bidding interval is over, the collected bids by
workers are used to execute the R-SMB auction mechanism.
The auction mechanism is executed for each zone individ-
ually using Ethereum Virtual Machines (EVMs). R-SMB
auction mechanism determines the allocation of tasks as well
as the payments of the workers. Allocated workers would
subsequently submit their solutions to the smart contract.
VOLUME 4, 2016 5

FIGURE 2: ABCrowd Framework Architecture: Smart Contract, Zones and Members
ABCrowd would then share the payments with the workers
and send back the solution along with the remaining budget
to the requester.
The framework, given in Fig. 2, shows the ABCrowd smart
contract, the zones with available tasks, and the interaction
between the requesters, workers, and the smart contract. The
zones represented as grids are an abstraction of the zone
objects within the smart contract.
B. TASK ZONES
In crowdsourcing frameworks scalability is a major concern
as many tasks concurrently exist. Ethereum makes scala-
bility even more challenging as the execution of on-Chain
functions is constrained by the transaction size limit 20 to
30 kb [25]. Therefore, the location of tasks in the proposed
crowdsourcing model is used to map/group tasks according
to their geographical locations into zones. A zone is deﬁned
as a z × z wide grid element of pre-determined coordinates
and a deﬁned ID. When a new task is shared by the requester,
the smart contract maps it to a given zone based on its
coordinates and is assigned its corresponding zone ID. This
allows the auction to be completely executed on-Chain and
improves the scalability of the auction on Ethereum.
The selection of the grid width, denoted by z, affects
the granularity of grouped tasks and the number of tasks
that are within a zone given their distribution. A smaller
z value implies a smaller zone area, which can lead to a
smaller number of tasks in a given zone when tasks are well
distributed. While this improves scalability, it can lead to
having many zones with a single task. This will converge our
solution to the greedy solution. On the other hand, a bigger
z value leads to more tasks being within the same zone,
which entails high execution cost for the auction charged
in a single-transaction. High execution cost can lead to
transactions being reverted in Ethereum as they exceed the
transaction cost limit. Therefore, the selection of z should
take into consideration the granularity the tasks require and
the currently permitted execution limit.
C. IMPLEMENTATION IN BLOCKCHAIN
To implement the proposed framework, a smart contract is
designed with multiple variables, data structures, mappings,
and functions. A TasksZones array of unsigned integers
(uint) holds the IDs of zones with available tasks for workers
to bid on. Two main data structures are designed, as shown in
Table 2, Task and Worker, with uint referring to unsigned
integer. Task maintains the information of a single task con-
sisting of its requester’s address, task budget, the task’s ID,
and location. Worker saves the information of a worker’s
bid given by the worker’s address, committed bid, revealed
bid as well as an array of the set of tasks he/she is bidding
for. This structure also holds the worker’s calculated rank and
whether the task is allocated or not.
TABLE 2: Smart Contract Data Structures
Task
Requester (address) Task ID (uint8) Location (bytes16)
Budget (uint)
Worker
Worker (address) Revealed Bid (uint) Committed Bid (bytes32)
Tasks (uint[]) Rank (uint) Allocated (bool)
Mappings are key-value pairs where a given key maps
to a saved value [26]. Mappings, as shown in Table 3, are
created to link each zone ID with the IDs of available tasks,
their general information, and workers’ bids for each zone.
TaskIDs maps zones to an array of available tasks’ IDs,
while TasksList maps a zone ID to an array of Task objects
for the general information of a task. WorkerBids maps
a zone ID to an array of Worker objects holding current
workers’ bids for that zone.
6 VOLUME 4, 2016

TABLE 3: Mappings within Smart Contract
Mapping Variable Key => Value
TaskIDs Zone ID => uint[]
TasksList Zone ID => Task[]
WorkerBids Zone ID => Worker[]
Table 4 shows implemented functions in the smart con-
tract, where addTask() is for the requesters to add their
tasks to the framework while getTasks() is mainly for
workers to find available tasks. The workers also use the
bid() and revealBid() functions to declare bids and set of
tasks they are interested in and consequently reveal their bids.
Lastly, allocationMechanism() and paymentFunction()
functions implement the R-SMB auction mechanism in Al-
gorithm 1. The usage of these functions is detailed in the
framework process in the following section.
TABLE 4: Smart Contract Functions
Function Parameters Return
addTask() Location,
Budget
-
getTasks() - TasksList
bid() Committed bid,
Tasks, Zone
-
revealBid() Revealed bid,
random
one-time value,
Zone
-
allocationMechanism() - Allocated workers
paymentFunction() - Workers’ payments
D. FRAMEWORK PROCESS
The overall framework process is shown in Fig. 3. It describes
the interaction between requesters, workers and the auction
smart contract. The red text elements are logs and functions
related to the smart contract while the black text reflects the
interactions initiated by the users.
User Registration: The requesters and workers are as-
sumed to be pre-registered in the crowdsourcing framework,
where they are able to publish new tasks or compete for
existing ones. Each of them is assumed to have a single
Ethereum address associated to his identity when bidding
in an auction. This prevents these workers from biasing the
outcome of the auction by submitting bids from multiple
accounts.
Creating Task: A requester interested in publishing a
task invokes the smart contract’s addTask(..) function.
addTask(..) requires the task’s budget, and location while
setting the requester’s address as the sender’s address. The
task’s zone is determined using its location to add it to the
available tasks in its corresponding zone ID in the TasksList
and TaskID. The zone ID is added to the TasksZones
variable track zones with available tasks.
Worker Bidding & Bid Revealing: A worker interested
in fulfilling tasks queries the getTasks(..) function. The
function returns the Available Tasks T for the worker to select
the set of tasks to bid for (Si). Algorithm 2 illustrates the
FIGURE 3: Framework Process Timeline: Deployment, Task
Requests, and Interactions for R-SMB
mechanism used by workers to select the set of tasks and zone
to bid for. First, each worker i determines Possible Tasks PT
to bid for according to lines 2 - 9. The worker is assumed to
be interested in bidding for tasks in proximity, within a radius
of interest ri, to maximize his/ her profit while minimizing
the travelled distance. The distance between the worker and
each available task j ∈ T is calculated. If it is within ri,
the task is a possible task to bid for. The corresponding bid
bij, which implies the cost given the worker’s distance, is
calculated as bij = z/dij. The cost increases with smaller
distance as a worker in proximity can complete the task
faster. Then, the task’s ID is added to PT along with bij and
the task’s zone ID. The task’s zone ID is added to the set of
zone IDs of possible tasks Zones (line 9).
With tasks belonging to zones of different locations, a
worker is interested in bidding for a set of tasks within
a single zone due to their relative proximity. The worker
determines the zone with maximum profit (according to lines
10 - 12). For each zone ID added to Zones, the bid for the
zone is calculated as the sum of the bids of tasks in it. Next,
the zone with maximum bid for each worker is identified
along with its set of tasks Si and the corresponding bid for
the worker bi.
While blockchain is introduced for execution transparency
in the framework, it conflicts with the desirable sealed-bid
property in truthful auctions. That is if a bid is shared with the
smart contract as plaintext, other workers can see it. Sealed-
bids are critical as they motivate workers to declare truthful
bids due to bidders’ limited knowledge of other workers’
bids. Hence, to maintain the privacy of bids, workers are
required to seal them before submitting them to the smart
contract. The sealed-bid is taken as a committed bid and
VOLUME 4, 2016 7

Algorithm 2 Task and Zone Selection
n = number of workers
m = number of tasks
T = set of available tasks
PT = set of possible tasks
Zones = set of zones with possible tasks
bk = bid for zone k
1: for i = 1, . . . , n do
2: PT = φ
3: Zones = φ
4: for j = 1, . . . , m do
5: dij = (xi − xj)2 + (yi − yj)2
6: if dij < ri then
7: bij = z
dij
8: PT ← PT ∪ {(j, bij, zonej)}
9: Zones ← Zones ∪ {zonej}
10: for k ∈ Zones do
11: bk = j∈P T &zonej ==k bij
12: [bi, w] = maxk∈Zones(bk)
13: Si = {∀j} : j ∈ PT & zonej == w
revealed later on to be verified by the smart contract before
executing the auction. Bid privacy is maintained during the
bidding interval where all workers submit sealed bids and
would only disclose them after it. This is sufficient for run-
ning the auction as no new bids are accepted while workers
are revealing their bids.
Cryptography can play a role in sealing bids by hashing
or encryption (symmetric or asymmetric keys). Encryption
provides privacy along with additional properties such as
authentication, integrity, and non-repudiation. However, it
cannot be executed on-Chain as solidity functions do not sup-
port encryption within the smart contract. Nevertheless, mul-
tiple hashing functions which provide privacy are supported
and can be executed with reasonable on-Chain cost such as
keccak256(), sha3(), ripemd160(), etc [18]. Sealing bids
through hashing entails two stages [8]: 1) Sealed Bidding and
2) Bid revealing.
For sealed bidding, a worker passes the calculated bid bi
from Algorithm 2 along with a random cryptography one-
time value rbi to a hashing function HASH(bi, rbi). The
function generates a fixed length t hash hi for the worker to
submit to the submitBid(..) function along with Si. Sealed-
bids are accepted while tbid interval has not finished.
For bid revealing, workers reveal their bids after tbid
finishes and while trevealBid interval has not finished to be
considered in the auction. A worker shares bi and rbi with the
revealBid(..) function which computes HASH(bi, rbi) and
verifies it is the same as the hi value submitted earlier by the
worker. If in agreement, the bid is considered in the auction,
otherwise the bid is assumed to be incorrectly revealed and is
dropped when the smart contract runs the auction.
R-SMB Auction Mechanism: Once trevealBid inter-
val is over, an iteration of the auction is executed for
each zone. The auction mechanism in Algorithm 1 is
implemented in the smart contract as two functions:
allocationMechanism(..) and paymentFunction(..) re-
spectively. The allocationMechanism(..) determines al-
located workers for each zone in WorkerBids mapping
according to the allocation mechanism, and sets allocated =
true in their Worker objects.
In paymentFunction(..), the payments for Worker ob-
jects in WorkerBids with allocated = true are calculated.
The payments denoted by the critical payment are determined
as mentioned in Algorithm 1. The payments are shared
with the workers directly from the smart contract using the
deposited budget by the requesters. Any remaining budget is
returned to the requesters.
While there are remaining tasks that are unallocated, the
auction is repeated for workers to rebid and get allocated
remaining tasks.
V. PERFORMANCE EVALUATION
The proposed ABCrowd framework is designed to enable an
on-Chain, cost-efficient, auction mechanism, R-SMB, with
similar performance to the optimized off-Chain VCG auc-
tion mechanism. Additionally, ABCrowd aims to maximize
the allocation of tasks as required by crowdsourcing while
motivating workers to fulfill multiple tasks.
To evaluate these goals, three evaluations are conducted.
1) The number of rounds required to maximize the alloca-
tion of tasks when deploying R-SMB is examined. 2) The
performance of the on-Chain R-SMB auction model with
the identified number of rounds is compared to the off-
Chain optimized VCG auction mechanism. 3) The cost of
deploying ABCrowd on the Ethereum blockchain is presented
to demonstrate its feasibility.
A. SETUP AND BENCHMARK
A real dataset [19] of radiation readings by approximately
500 workers is used in the evaluation. Table 5 presents: 1)
the geographical area used, 2) the task parameters that are
generated randomly within the area of interest, as well as 3)
the R-SMB auction parameters used.
Vickrey-Clarke-Grooves (VCG) [4] auction mechanism is
chosen as the benchmark to compare the performance of R-
SMB and the optimum VCG. VCG, by design, aims at maxi-
mizing the social welfare when allocating tasks T to workers
W, with a maximum of one worker being allocated each
task. The payments of allocated workers are then calculated
based on their social contributions. Below is the formulation
of the problem and the payment function used to generate the
8 VOLUME 4, 2016

TABLE 5: Evaluation Parameters
Dataset Parameters
Number of Workers ≈ 500 (490 workers)
Area (Latitude, Longitude) ([35, ...,44],[136,.. .,142])
Data Type Radiation Level (µSV )
Task Parameters
Number of Tasks [50-250]
Location (Latitude, Longitude) [[35,...,44],[136,... ,142]]
Task Budget [$0.01,...,$4]
R-SMB Parameters
Worker maximum tasks 20
Worker’s radius of interest (r) 2
Maximum rounds (ar) 5
Zone range (z) 2
Random One-time value (rb) [0,...,255]
Hashing Function (HASH) Keccak256
tbid and trevealBid [100 Blocks] ≈ 20 minutes [27]
evaluation results for the VCG mechanism [28].
Z(v) = max
i∈W j∈T
vij × xij (1)
s.t.
i∈W j∈T
xij ≤ |T| (2)
i∈W
xij ≤ 1 (3)
xij ∈ {0, 1}∀i, j (4)
pi = Z(0, bi) −
i =i
bi (Si ) (5)
To study the cost and feasibility of ABCrowd, it is imple-
mented in Solidity 0.5.1 [18], the programming language for
Ethereum blockchain, and tested with a ganache client [29].
Several addresses are created to map workers and requesters
interacting with the framework.
B. R-SMB AUCTION MECHANISM - ROUNDS
Before comparing the proposed R-SMB auction mechanism
with VCG, its performance is studied to understand the num-
ber of repetition rounds needed for the auction to maximize
the number of allocated tasks. For a crowdsourcing frame-
work, the number of R-SMB rounds to run is determined as
the average number required to allocate all the tasks in the
framework.
Fig. 4 presents the maximum number of rounds that the re-
peated auction requires to allocate all the tasks when varying
both the number of workers in the framework and the number
of tasks. It can be seen that with more tasks being avail-
able for workers, the average number of maximum rounds
increases for the different sets of workers. Nevertheless, an
the number of maximum rounds is the same at higher number
of workers, i.e. 400 and 500 workers.
When increasing the number of workers, the maximum
number of rounds, for a constant number of tasks, decreases.
More workers being available to bid for the tasks allows a
bigger number of tasks to be allocated within a round. The
decrease is clearly notable in the case of maximum number of
tasks (250 tasks) as the ratio between the number of workers
and the tasks is the highest. A similar trend is observed in
the different numbers of tasks evaluated. The identiﬁed max-
imum number of rounds is ceiled and used when evaluating
the performance of R-SMB auction mechanism against VCG
mechanism.
FIGURE 4: R-SMB Maximum Rounds
C. AUCTIONS PERFORMANCE
To compare between on-Chain R-SMB and off-Chain VCG,
three metrics are evaluated: 1) number of allocated tasks, 2)
workers’ travelled distance, and 3) requesters’ total cost.
Tables 6 - 10 show the average number of allocated tasks
by VCG and R-SMB per each round. It can be seen that
R-SMB allocates an increasing number of tasks as a conse-
quence of repeating the auction and allowing workers to rebid
for the remaining tasks for maximum task allocation. The
average number of allocated tasks by R-SMB number at the
last round is mostly comparable to VCG. Both mechanisms
are able to allocate more than 90% of the tasks.
TABLE 6: Allocated Tasks (50 tasks)
Workers Tasks VCG
R-SMB (each round)
1 2 3
100 50 48.8 41.4 48.4 50
200 50 48.6 43 48.6 48.6
300 50 49.6 44 49.6 49.6
400 50 49.6 44.8 49.6 49.6
500 50 50 44.8 49.8 50
Workers Tasks VCG
R-SMB (each round)
1 2 3
100 100 98.4 83 96.8 98.4
200 100 100 85.6 99.6 100
300 100 100 84.4 99.2 100
400 100 100 85.2 99.2 100
500 100 100 86 99.6 100
VOLUME 4, 2016 9

(a) 50 Tasks (b) 100 Tasks (c) 150 Tasks
(d) 200 Tasks (e) 250 Tasks
FIGURE 5: Workers’ Travelled Distance
Workers Tasks VCG
R-SMB (each round)
1 2 3
100 150 144.2 119.4 139.8 144.2
200 150 147 122.2 145.4 147
300 150 150 125.8 148.4 150
400 150 148.6 124.2 147.6 148.3
500 150 150 126.4 148.6 150
Workers Tasks VCG
R-SMB (each round)
1 2 3 4
100 200 194.4 155.2 188 194.2 200
200 200 197.4 159.2 193.4 197.4 197.4
300 200 199.4 161.2 195.2 199.4 199.4
400 200 200 161.8 196 200 200
500 200 200 161.8 196.4 200 200
Workers Tasks VCG
R-SMB (each round)
1 2 3 4
100 250 239.29 182.8 224.4 233.6 232.25
200 250 241.43 187.4 229.6 236.4 237
300 250 246.53 191 235 241.2 245
400 250 246.94 192.6 234.6 242 242
500 250 250 197.6 238.6 245 245
Fig. 5 presents the total travelled distance by the selected
workers to perform the tasks. It can be clearly seen that R-
SMB leads to a much smaller travelled distance compared to
VCG with the same number of tasks being fulfilled according
to Tables 6 - 10. This is a result of allocating tasks on multiple
rounds while considering workers’ updated locations at the
different rounds. Hence, tasks can be allocated to a worker
that becomes within proximity of other tasks after a given
round. Alternatively, VCG independently and optimally allo-
cates each task to a worker in a single step manner.
Figs. 5a - 5e each presents the travelled distance by work-
ers for increasing number of tasks. In the case of R-SMB,
the distance increases with the increase in the number of
workers consistently at all of the figures as the allocation is an
approximation based on available workers and their bids. On
the other hand, VCG increases but in a more gradual trend as
optimal workers are assigned in this mechanism for all of the
considered cases. It can also be noticed that the difference
between the two auction mechanisms increases with higher
number of tasks as R-SMB selects workers within close
proximity to the tasks at the different rounds when compared
with VCG which optimally selects workers in a single run.
Fig. 6 shows the total cost endured by requesters for their
completed tasks. With R-SMB requiring workers to travel a
shorter distance, the total cost endured by the requesters is
smaller than when using VCG mechanism. The cost in R-
SMB increases with more workers available for the different
numbers of tasks as the cost is based on workers’ contri-
butions. Better workers completing the tasks require higher
cost for their accomplishment of tasks. The smaller cost in
R-SMB compared to VCG motivates requesters to use the
proposed framework to efficiently use their budget.
10 VOLUME 4, 2016

(a) 50 Tasks (b) 100 Tasks (c) 150 Tasks
(d) 200 Tasks (e) 250 Tasks
FIGURE 6: Workers’ Travelled Distance
D. ABCROWD SMART CONTRACT COST
The cost of deploying ABCrowd smart contract and executing
its functions on the Ethereum blockchain are presented to
demonstrate its feasibility and cost-efficiency. The execution
involves 100 workers who are bidding for 50 tasks in dif-
ferent zones. The execution cost of the different functions is
collected as consumed gas collected from the mined trans-
actions, which is converted to Ether cost for a gas price of
5 × 10−9
Ether (5 Gwei). This value leads to an average
transaction confirmation time of 0.8 minutes [27]. The cost
is also evaluated in money-terms by considering 1 Ether =
$182.2 (as of November 17th
2019) [30]. Table 11 presents
the cost of each function in the three different units.
TABLE 11: Cost of Framework Functions
Functionality Gas Consumption Ether Cost USD Cost
Deployment 3149143 0.00945 1.72
addTask 115714 0.00035 0.064
Bid 149305 0.00045 0.082
revealBid 80403 0.00024 0.044
R-SMB (1 round) 3989722 0.01197 2.18
Contract deployment cost is a one-time cost endured to
create and deploy the auction contract on the Ethereum
blockchain by the framework admin and requires no extra
cost for its maintenance. The addTask cost includes adding
the task to its corresponding zone array in the smart contract.
The Bid cost involves adding the worker’s bid information to
the zone of the bidding tasks and revealBid involves verifying
the bid and the random one-time value by finding their hash
and comparing it to the actual submission.
For the auction, the cost of running the allocation mech-
anism and the payment function on multiple zones with 50
tasks is $2.18 ≈ $0.0436 per task, which is paid by the
requesters for the execution of the auction with no additional
service fee. R-SMB auction function requires the highest cost
due to the sorting functions and loops used to determine
the allocations and payments. However, with the cost of
the auction being divided equally on the requesters of tasks
within the zones, the cost per task becomes reasonable for
interested requesters.
In [8], the only other auction model deployed fully on
Ethereum is presented which costs $11.09 when 20 bidders
are engaged. R-SMB auction model shows a much lower cost
for a bigger number of bidders. However, the cost of the auc-
tion is not directly compared in the performance evaluation
as their objectives are different. The latter auction mechanism
is concerned with overcoming collusion of bidders interested
in buying k-item for the same price. On the other hand,
R-SMB auction mechanism considers this collusion out of
scope as bidders are competing for the allocation of tasks.
Meanwhile, looking at a centralized crowdsourcing platform,
such as Mechanical Turk (MTurk) [31], where a service fee
of at least 20% from the total reward is endured by requesters.
These service fees do not exist for ABCrowd while only the
execution cost is charged.
In summary, the collected costs for the functions are
relatively small with no additional service fees required by
any party. Hence, the proposed framework is an appropriate
alternative to centralized platforms which enforce service
fees on participants, requesters, and workers.
VOLUME 4, 2016 11

VI. CONCLUSION
In this work, a fully distributed crowdsourcing framework
is proposed which implements auction mechanisms over
blockchain - ABCrowd. ABCrowd tackles two main chal-
lenges: trusted execution through blockchain and workers’
truthfulness through R-SMB truthful auction mechanism.
Blockchain is utilized to eliminate the dependency on cen-
tralized platforms to handle users interaction and task al-
location by moving to a transparent on-Chain execution.
Meanwhile, an on-Chain R-SMB auction mechanism is pro-
posed and used to motivate workers to advertise their truthful
costs. Comparing the on-Chain R-SMB to the optimized off-
Chain VCG mechanism demonstrates that R-SMB provides
an approximate performance to VCG in terms of number of
allocated tasks while outperforming in the workers’ travelled
distance and requesters’ total cost. Finally, ABCrowd needs
low execution cost with no service charges, as commonly re-
quired in centralized platforms, making the proposed frame-
work financially competent.
REFERENCES
[1] D. G, “60+ revealing statistics about smarthpone usage in 2019,” 2019.
[Online]. Available: https://techjury.net/stats-about/smartphone-usage/
[2] M. Priyadarshini, “Which sensors do i have in my smartphone? how
do they work?” 2019. [Online]. Available: https://fossbytes.com/which-
smartphone-sensors-how-work/
[3] L. G. Jaimes, I. J. Vergara-Laurens, and A. Raij, “A survey of incentive
techniques for mobile crowd sensing,” IEEE Internet of Things Journal,
vol. 2, no. 5, pp. 370–380, Oct 2015.
[4] W. Vickrey, “Counterspeculation, auctions and competitive sealed ten-
ders,” Journal of Finance, vol. 16, no. 1, pp. 8–37, 1961, cited By 22.
[5] T. Luo, S. S. Kanhere, J. Huang, S. K. Das, and F. Wu, “Sustainable
incentives for mobile crowdsensing: Auctions, lotteries, and trust and
reputation systems,” IEEE Communications Magazine, vol. 55, no. 3, pp.
68–74, March 2017.
[6] Y. Jiao, P. Wang, D. Niyato, and Z. Xiong, “Social welfare maximization
auction in edge computing resource allocation for mobile blockchain,”
in 2018 IEEE International Conference on Communications (ICC), May
2018, pp. 1–6.
[7] N. C. Luong, Z. Xiong, P. Wang, and D. Niyato, “Optimal auction for
edge computing resource management in mobile blockchain networks:
A deep learning approach,” in 2018 IEEE International Conference on
Communications (ICC), May 2018, pp. 1–6.
[8] S. Wu, Y. Chen, Q. Wang, M. Li, C. Wang, and X. Luo, “Cream: A
smart contract enabled collusion-resistant e-auction,” IEEE Transactions
on Information Forensics and Security, vol. 14, no. 7, pp. 1687–1701, July
2019.
[9] H. Galal, “Verifiable sealed-bid auction on the ethereum blockchain,” 03
2018.
[10] H. Galal and A. M Youssef, “Trustee: Full privacy preserving vickrey
auction on top of ethereum,” 02 2019.
[11] A. Sonnino, M. KrÃ¸sl, A. G. Tasiopoulos, and I. Psaras, “Asterisk:
Auction-based shared economy resolution system for blockchain,” 01
2019.
[12] D. Chatzopoulos, S. Gujar, B. Faltings, and P. Hui, “Privacy preserving and
cost optimal mobile crowdsensing using smart contracts on blockchain,” in
2018 IEEE 15th International Conference on Mobile Ad Hoc and Sensor
Systems (MASS), Oct 2018, pp. 442–450.
[13] M. Xiao, K. Ma, A. Liu, H. Zhao, Z. Li, K. Zheng, and X. Zhou, “Sra:
Secure reverse auction for task assignment in spatial crowdsourcing,”
IEEE Transactions on Knowledge and Data Engineering, pp. 1–1, 2019.
[14] Y. Wei, Y. Zhu, H. Zhu, Q. Zhang, and G. Xue, “Truthful online double
auctions for dynamic mobile crowdsourcing,” in 2015 IEEE Conference
on Computer Communications (INFOCOM), April 2015, pp. 2074–2082.
[15] H. Huang, Y. Xin, Y. Sun, and W. Yang, “A truthful double auction
mechanism for crowdsensing systems with max-min fairness,” in 2017
IEEE Wireless Communications and Networking Conference (WCNC),
March 2017, pp. 1–6.
[16] X. Zhang, G. Xue, R. Yu, D. Yang, and J. Tang, “Truthful incentive
mechanisms for crowdsourcing,” in 2015 IEEE Conference on Computer
Communications (INFOCOM), April 2015, pp. 2830–2838.
[17] J. O. Ledyard, “Optimal combinatoric auctions with single-minded
bidders,” in Proceedings of the 8th ACM Conference on Electronic
Commerce, ser. EC ’07. New York, NY, USA: ACM, 2007, pp. 237–242.
[Online]. Available: http://doi.acm.org/10.1145/1250910.1250945
[18] “Solidity,” 2018. [Online]. Available:
https://solidity.readthedocs.io/en/latest/
[19] M. Venanzi, A. Rogers, and N. R. Jennings, “Crowdsourcing spatial
phenomena using trust-based heteroskedastic gaussian processes,” 2013.
[Online]. Available: https://eprints.soton.ac.uk/354861/
[20] V. Krishna, Auction Theory. Elsevier Science, 2009. [Online]. Available:
https://books.google.ae/books?id=qW1128ktG1gC
[21] 2019. [Online]. Available: https://www.ebay.com/help/selling/fees-
credits-invoices/selling-fees?id=4364
[22] T. Pedersen and B. Petersen, “Explaining gradually increasing
resource commitment to a foreign market,” International Business
Review, vol. 7, no. 5, pp. 483 – 501, 1998. [Online]. Available:
http://www.sciencedirect.com/science/article/pii/S0969593198000122
[23] E. F. Brickell, D. Chaum, I. B. Damgård, and J. van de Graaf, “Gradual
and verifiable release of a secret (extended abstract),” in Advances in
Cryptology — CRYPTO ’87, C. Pomerance, Ed. Berlin, Heidelberg:
Springer Berlin Heidelberg, 1988, pp. 156–166.
[24] G. Wood, “Ethereum: a secure decentralised generalised transaction
ledger,” Ethereum Project Yellow Paper, vol. 151, 2014.
[25] “What’s the maximum ethereum block size?” 2019. [Online]. Available:
https://ethgasstation.info/blog/ethereum-block-size/
[26] Ethereum, “Solidity Documentation,” 2018. [Online]. Available:
https://media.readthedocs.org/pdf/solidity/develop/solidity.pdf
[27] “Ethereum gas station,” 2019. [Online]. Available:
https://ethgasstation.info/
[28] N. Nisan, T. Roughgarden, E. Tardos, and V. V. Vazirani, Algorithmic
Game Theory. New York, NY, USA: Cambridge University Press, 2007.
[29] 2019. [Online]. Available: https://www.trufflesuite.com/ganache
[30] “Ethereum price,” 2018. [Online]. Available: https://ethereumprice.org/
[31] “Amazon mechanical turk,” 2018. [Online]. Available:
https://www.mturk.com/
12 VOLUME 4, 2016

ABCrowd: An Auction Mechanism on Blockchain for Spatial Crowdsourcing

Recommended

Recommended

More Related Content

Similar to ABCrowd: An Auction Mechanism on Blockchain for Spatial Crowdsourcing

Similar to ABCrowd: An Auction Mechanism on Blockchain for Spatial Crowdsourcing (20)

Recently uploaded

Recently uploaded (20)

ABCrowd: An Auction Mechanism on Blockchain for Spatial Crowdsourcing