AStERISK: Auction-based Shared Economy ResolutIon System for blocKchain

01/23/2019 ∙ by Alberto Sonnino, et al. ∙ UCL 0

Recent developments in blockchains and edge computing allows to deploy decentralized shared economy with utility tokens, where altcoins secure and reward useful work. However, the majority of the systems being developed, does not provide mechanisms to pair workers and clients, or rely on manual and insecure resolution. AStERISK bridges this gap allowing to perform sealed-bid auctions on blockchains, automatically determine the most optimal price for services, and assign clients to the most suitable workers. AStERISK allows workers to specify a minimal price for their work, and hide submitted bids as well the identity of the bidders without relying on any centralized party at any point. We provide a smart contract implementation of AStERISK and show how to deploy it within the Filecoin network, and perform an initial benchmark on Chainspace.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 3

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

The cloud computing model developed during the last two decades was built on the premise of compute centralization. That is, computing power is geographically and administratively concentrated in compute infrastructures of industrial scale, generally called datacenters. As a result, the majority of users currently rely on clouds for applications such as hosting services, offloading computation, and data storage. However, centralization introduces several drawbacks; cloud computing services act as large central points of failure [awsdown], and make possible for authorities to enforce censorship [awscensor] or violate user privacy [debatin2009facebook]. Furthermore, large cloud operators often abuse their market position to effectively force users to trust their service and adapt to operators’ rules and prices.

Recent research efforts focus on shared-economy infrastructures, where services are performed by users sharing their resources with each other at the edge of the network [abbas2018mobile]. Such infrastructures can provide better quality of service, and reduce the exposure to central points of failures and abuse of power; but require security solutions and reliable incentive mechanisms to compensate the lack of trust between distributed users. Following the recent success of Bitcoin [bitcoin] a large amount of cryptocurrency projects implement such a shared economy model and use blockchains to secure their platforms and simplify payments [golem, sonm, iexec, bounty0x, combinatorjune, protocol2017por]. The vision is to create a decentralized system, where users are incentivized to perform useful work and automatically receive rewards upon tasks completion.

While multiple projects focus on the crucial task of proving to the network that a service has been successfully completed [airtnt, krol2018spoc, miller2014permacoin, benet2018proof], an equally important task of determining an optimal price for those services has been largely ignored by the community. Furthermore, industrial projects either do not cover this problem or rely on manual user interaction causing multiple scalability and security issues [golem, sonm, iexec, bounty0x]. In this work, we answer to the question of how blockchains and smart contracts can be leveraged for deriving the price of a service in distributed computing infrastructures and automatically assign service requesters to corresponding workers.

Clearly, the providers of the distributed infrastructure are expected to ask for compensation, since admitting user requests will impose operational expenses while occupying their personal computing as well as storage resources. Therefore, the sufficient participation of infrastructure providers is associated with an incentivisation mechanism that allows them to profit by offering their resources at a price that equals or exceeds, their expenses. That is, the objectives of users and providers are conflicting with each other since the former try to access a service at the lowest possible price while the latter try to maximise their revenue. Therefore, there is a need for a market mechanism that will intervene, in the form of an auction, to ensure the effective association between user requests to providers’ resources. By running auctions on blockchain, user do not have trust each other nor any trusted 3 party, they inherit security guarantees from the underlying distributed ledger and can be sure that auction is performed correctly using Smart Contracts. However, data submitted to blockchain automatically becomes public and in sealed-bid auctions it is critical to hide all the bids during the auction. Moreover, revealing bidders identity imposes another security threat; i.e., revealing that a bidder bought storage space at two servers makes the servers an easy target for malicious users willing the bidder to lose their data.

In this paper we propose AStERISK— an auction-based shared economy resolution system running on top of distributed ledger. In AStERISK, workers submit their offers to the blockchain together with a minimal price they are willing to accept. Our system hides submitted bids and protects bidders identity using anonymous credentials. In contrast to related work, AStERISK does not rely on a single trusted 3 party to issue all the credentials, but rather on a set of multiple, decentralised authorities. Each user can define their own set trusted parties and is protected from a subset of authorities becoming malicious. Once an auction is finished, AStERISK automatically creates a binding on the blockchain allowing workers to claim money from requester deposits upon submission of a valid proof of useful work. For simplicity, we focus on the case of Filecoin [filecoin], a decentralized storage network, but AStERISK can be easily adapted to work with additional systems implementing a shared economy model.

Ii Background

Blockchain

The blockchain technology [bitcoin] implements a distributed, append-only ledger in the form of connected blocks; once information is stored in the blockchain it cannot be removed or altered. Network participants use a consensus protocol to agree on the current state of the ledger, and the system maintains its properties as long as a subset of the participants is honest. Blockchains are used to record crypto-currencies (e.g.,, Bitcoin [bitcoin], Ethereum [buterin2013ethereum]) transactions. A common extension consisting of scripting languages enables to include logic as part of the transaction and allows deployment of smart contracts—code submitted to the blockchain and executed by all network participants. AStERISK leverages the high-integrity data structure provided by blockchains, and uses it for accountancy, auditability, and time reference (e.g., time may be define as the block height of the main chain).

Filecoin

At the core of Filecoin lies a Storage Market that allows requesters to pay miners, to store data. Specifically, a Storage Market acts as an exchange point where clients and miners can advertise their requests and offer resources. The Network guarantees that the miners are rewarded by the clients when providing the service. Filecoin uses Proof-of-Replication [benet2018proof] a scheme that relies on zero-knowledge Succinct Non-interactive ARguments of Knowledge (zk-SNARKs) [gennaro2013quadratic, ben2013snarks] allowing a Prover to prove possession of data . To prevent Sybil attacks and allow proving possession of multiple copies of the same file, Proofs-of-Replication are generated over a version of data encrypted under a key specified by the requester such that . Filecoin requires the Prover to recursively and continuously generate those proofs with randomness r obtained from the most recent block in the blockchain and thus proving possession of the file over time.

Anonymous Credentials

Anonymous credentials [amac, pointcheval] allow the issuance of credentials to users, and the subsequent unlinkable revelation to a verifier. Users can selectively disclose some of the attributes embedded in the credential or specific functions of these attributes. Most anonymous credentials scheme entrust a single authority with a master credential signature key, allowing a malicious authority to forge any credential. Other schemes do not provide the necessary re-randomization or blind issuing properties necessary to implement general purpose disclosure credentials. To overcome these limitations, AStERISK relies on Coconut [coconut] which supports distributed threshold issuance of credentials; therefore supporting private attributes, re-randomization, and unlinkable multi-show selective disclosure without relying on a central trusted 3 party. Coconut is designed for use in the context of blockchains to ensure confidentiality, authenticity and availability even when a subset of credential issuing authorities are malicious or offline; and uses short and computationally efficient credentials that can easily be verified by a smart contract. Colluding authorities can forge Coconut credentials, but cannot break unlinkability and de-anonymize users. Coconut authorities issue credentials without communicating with each other, following a standard key distribution phase; as a result, a large number of authorities may be used to issue credentials without significantly affecting efficiency.

Iii Design Goals

AStERISK associates worker resources to users via the execution of an auction mechanism. Specifically, we consider a system with the following actors:

  • Bidders - users willing to access a services (e.g., Filecoin users wishing to store some data in the network).

  • Workers - offer their services to the users (e.g., Filecoin miners wishing to store users file for specific prices).

  • Authorities - distributed system responsible to issue credentials allowing users to participate in auctions.

AStERISK assumes that at least a threshold subset of the authorities are honest; all cryptographic operations rely (or are implied by) the XDH assumption [bls]; and relies on weak synchrony111Weak synchrony [bft] is required by many smart contract platforms [chainspace, omniledger], and by distributed key generation protocols required by Coconut [coconut]. for liveness (but not for safety). These assumptions are inherited from Coconut, and the underlying smart contract platform. Given this threat model, AStERISK achieves the following design goals:

  • Hidden Minimum Price: Workers can specify a minimum price for which they are willing to perform given actions, and are guaranteed that the winner of the auction bids at least that price. This minimum price is kept private from the bidders until the end of the auction.

  • Bidders Privacy: Bidders are unlinkable to to their bids. Only the identity of the winner is revealed to the worker (at the end of the auction).

  • Bids Privacy: Bids are kept private until the end of the auction; bidders submit their bids without knowledge of what other bidders do.

  • Bids Binding: Bidders cannot change their bids once they are committed.

  • Public Auditability: Anyone can verify the correct execution of any auction.

  • Fairness: Bidders are financially penalized if they deviate from the protocol, but cannot be financially penalized if they follow it correctly. Bidders cannot double-spend coins [karame2012double], and no authority can steal bidder’s funds.

  • Non-Interactivity: Bidders are not required to interact with each other.

  • Censorship Resistance: Anyone can act as bidder or worker; the system is resilient to censorship.

  • Distributed Authority: AStERISK never relies on a single trusted 3 party.

  • Auction’s economic properties: Involving i) Efficiency, in terms of assigning resources to the bidders that value them the most in a computationally feasible way, ii) Incentive Compatibility (Truthfulness), where bidders and workers benefit by revealing their true valuations, iii) Individual Rationality, where both bidders and workers are willing to participate, and iv) Budget Balance, where the payments submitted cover workers’ compensations.

Iv AStERISK Design

(a) Preparation phase.
(b) Auction phase.
(c) Execution phase.
Fig. 1: Overview of auction executions on AStERISK

Iv-a AStERISK Smart Contract

We design AStERISK as a smart contract that extends the tumbler application of Coconut [coconut] to allow credentials to be used as anonymous bids in auctions222The tumbler application is described at Section V.A of Coconut [coconut].. The AStERISK smart contract defines six functions (Setup, Create, Deposit, Commit, Reveal, Withdraw):

[leftmargin=1em, labelindent=0em]

Setup:

A set of authorities jointly create an instance of the AStERISK contract by providing their public keys as well as any other scheme parameters as the number of authorities and the threshold parameter. This function can be run multiple time, and by different sets of authorities; the workers then select the set of authorities they trust upon executing Create.

Create:

Any 3 party worker creates an auction by specifying the set of authorities trusted to issue credentials, as well as any application specific parameter or policy. They also specify, a commitment to the minimum price for which they are willing to operate; and two time-tamps333Time may be defined as the number of blocks built on top of the main chain of the blockchain., and (where ) used during the auction phase (see Section IV-B).

Deposit:

Bidders deposit coins into a buffer account specified by the smart contract to request a credential on the public attribute , and on a private randomly generated sequence number . To prevent tracing traffic analysis, should be limited to a specific set of possible values, similar to cash denominations. Each authority monitors the AStERISK smart contract, and issue a partial credential to the user—either on chain or off-chain—upon detecting a credential request (credential requests are processed only if bidders paid a deposit of coins to the smart contract). bidders locally aggregate all partial credentials into a consolidated credential.

Commit:

Bidders submit a bid by showing a valid credential to the smart contract; they also provides a proof of knowledge of the sequence number along with a group element uniquely built from . If the proof and the credential check, the smart contract records . The group element embeds the sequence number and is therefore bound to the credential and the number of coins it embeds—showing effectively commits to . The smart contract accepts the bidders input only before .

Reveal:

Bidders reveal , , and the credentials, as well as a proof that is correctly embedded in the credentials and asserting correctness of . The smart contract accepts the bidders input only after and before , and if the smart contract previously recorded (i.e., if the bidder committed to its bid). Workers open the commitment to the minimum price they committed to during Create.

Withdraw:

To withdraw the coins, the bidder provides the smart contract with a zk-proof of knowledge of their private key by binding the proof to the address where they wish to redeem the coins; they also provides the consolidated credential, , and a zk-proof attesting its correctness. To prevent double spending, the contract keeps a record of all group elements that have already been shown. Upon showing a embedding a fresh (unspent) sequence number , the contract verifies the credential and zero-knowledge proofs, and that doesn’t already appear in the spent list. Then, it withdraws coins from the buffer and sends them to the specified address , and adds to the spent list. Bidders can only withdraw coins after , and only credentials that have been recorded by Commit and Reveal can be used to withdraw coins (this effectively lock the funds of bidders that deviate from the protocol). According to the policy set upon executing Create, the winner of the auction may be treated differently.

SubmitWork:

After , the winner contacts the worker through a private channel, and uploads cryptographic material to the smart contract allowing the worker to retrieve its payment. Winners can anonymously prove they actually won the auction by proving possession of the consolidated credential, , and a zk-proof attesting its correctness. In the case of Filecoin, the winner proves they won the auction to the smart contract, and uploads a hash of the encrypted file to store along with a signature. The file hash is then used to verify Proofs of Spacetime [benet2018proof] submitted by the worker and release payments from the bidder’s deposit over time.

Iv-B The AStERISK Protocol

Figure 1 shows the execution of an auction on AStERISK; the auction is divided in three phases:

  • Preparation phase (Figure 0(a)): Bidders pay deposits and retrieve a credential required to participate in auctions, and storage nodes submit their offers.

  • Auction phase (Figure 0(b)): Bidders commit and later reveal their bids. The smart contracts determines the winner by applying a Vickrey auction mechanism [vickrey1961counterspeculation].

  • Execution phase (Figure 0(c)): Auction winner contacts its corresponding storage nodes, prove their identity and submit files to store. Storage node receives rewards for storing files over time.

Preparation phase

A set of authorities executes the Setup function of the AStERISK smart contract described in Section IV-A. Any worker executes Create (Figure 0(a)-➌) to create an auction by specifying the auction parameters, and which set of authorities they trust. They also specify the two time-tamps, and determining the auction’s time line; workers advertise their product and provide a commitment to a minimum price at which they are willing to operate. Bidders execute Deposit by paying a deposits of coins into a buffer account specified by the AStERISK smart contract (Figure 0(a)-➊), and retrieve a credential required to participate in auctions (Figure 0(a)-➋). The value represents the number of coins they wish to bid.

Auction phase

Bidders execute Commit (Figure 0(b)-➊) to commit to a bid for a particular auction on the smart contract. Bidders commitments are only considered valid if submitted before the deadline . Next, workers open the commitment to their minimum price, and bidders call Reveal (Figure 0(b)-➋) to open their commitment to the smart contract; bidders openings are valid only if submitted before the deadline . Finally (Figure 0(b)-➌), the winner of the auction is deduced from the execution trace of the smart contract. The group element associated with the highest (if ) indicates the winner of the auction—all bidders that correctly followed the protocol (except the winner) may withdraw their coins calling the Withdraw function of the AStERISK contract. If there is no winner, the auction fails and every bidder may withdraw their money. AStERISK applies a Vickrey auction mechanism [vickrey1961counterspeculation]; the winner of the auction is the bidder with the highest bid , and pays the price of the second highest bid, . That is, the winner is free to call Withdraw to withdraw coins.

Execution phase

The winning bidder execute SubmitWork (Figure 0(c)-➍) and submits hashes of the encrypted files to store. They then contact the corresponding worker off-chain, prove they are the rightful winner by showing their credential, and directly transmits the file replica to the worker. The worker can then start generating proofs of useful work, submit them to the blockchain, and claim rewards from the winner’s deposit. Verifying the proof of useful work and releasing the payment is an integral part of the underlying blockchain, and is out of the scope of this work.

V Discussion

AStERISK involves worker specific contracts that offer resources in the form of a single item. In practice more sophisticated auctions are of interest where multiple workers offer their resources in the form of multiple items while bidders express their bids for a subset of them on the same contract; such ambition comes at the challenges of (i) auction execution, and (ii) bidding privacy and security.

With respect to the auction execution, it has been shown that combinatorial auction can be modelled as the set packing problem, meaning that they are NP-hard and there is no polynomial-time algorithm for finding the optimal allocation. A solution would be to consider a system where bidders are associated into up to a single item. That would lead to a computationally feasible and efficient assignment, i.e., multi-item unit demand auction [andersson2013multi]

setting, on the expense however of bidders’ flexibility in expressing their preferences. On the other hand, the bidders are expected to submit a vector of bids,

i.e., one bid for each offered item. Although the Deposit function can be easily scaled up, i.e., by putting as a deposit the sum of bids or the maximum bid in a vector, the analysis of such vectors of bids could reveal information on the bidder andcreate a privacy challenge that has to be addressed.

Vi Protocol Analysis

We argue how AStERISK achieves the design goals described in Section III.

Hidden Minimum Price

Upon the execution phase of the auction, AStERISK guarantees that a worker will offer their resources at a price higher than the minimum price or not offer their resources at all.

Bidders privacy

AStERISK takes advantage of Coconut’s unlinkability property to break the link between the deposit of coins, the commit of bids, and the withdraw of the coins. As a result, bidders can submit bids on auctions without revealing their identity, yet proving possession of a valid credential.

Bids privacy

Bids are kept private until ; the zero-knowledge property of Coconut credentials implies that no information about is revealed while committing to a bid (Figure 0(b)-➊).

Bids binding

Bidders are bound to their bids as they are first required to commit to their bid (Figure 0(b)-➊), and then to open the commitment (Figure 0(b)-➋). Bidders cannot open the commitment to another value than the previously committed as this implies forging the Coconut credentials.

Public auditability

AStERISK is implemented as a smart contract; its correct execution can be verified by any 3 party by taking advantage of the public auditability of the underlying smart contract plateform.

Fairness

No single authority can create credentials and steal all the coins in the buffer account of the smart contract—the threshold property of Coconut implies that adversaries need to corrupt an arbitrarily large set of authorities for this attack to be possible. Bidders cannot participate to the auction phase (Figure 0(b)) without paying a deposit to receive a valid credential; setting forces the bidders to commit to their bid before revealing it, preventing any 3 party from seeing other bidder’s bid before committing to a value. Bidders dropping out after committing a bid (and never revealing it) are financially penalized as they cannot withdraw their coins. Coconut provides blind issuance which allows bidders to obtain a credential on the sequence number without the authorities learning its value. Without blindness, any authority seeing could potentially race the bidders, and withdraw the coins of the credential—blindness prevents authorities from stealing the coins. Keeping a spent list of all group elements prevents double-spending attacks [karame2012double] without revealing the sequence number ; this prevents an attacker from exploiting a race condition upon withdrawing and which may lock bidders coins.

Non-interactivity

Bidders do not interact with each other. During the preparation phase (Figure 0(a)), Bidders only interact with a subset of the the authorities to receive a credential; during the auction phase (Figure 0(b)), they only interact with the smart contract; during the execution phase (Figure 0(c)), bidders only interact with the workers or with the smart contract to withdraw their coins.

Censorship resistance

The decentralized nature of the underlying smart contract platform makes the AStERISK smart contract resilient to censorship. Furthermore, a small subset of authorities cannot block the issuance credentials—the service is guaranteed to be available as long as at least a threshold number of authorities are running.

Distributed authority

AStERISK introduce no single trusted 3 party; the AStERISK contract is executed on a decentralized smart contract platform, and Coconut allows threshold issuance of credentials.

Auction’s economic properties

An auction satisfies all those properties only under the condition of price-taker participants [myerson1983efficient], i.e., both bidders and workers have no impact on the auction prices. In the single item auctions we consider here, it has been proven that Vickrey auctions possesses all these desired attributes based on the assumption of “sealed bids”, where neither bidders nor workers have information about the state of the auction [vickrey1961counterspeculation]. AStERISK through its privacy properties provides a technical implementation of the “sealed bids” assumption which prevents price manipulations.

Vii Implementation & Evaluation

AStERISK Chainspace smart contract
Operation [ms] [ms] size [kB]
Create [g] 28.433 0.214
Create [c] 0.0148 0.002 -
Commit [g] 194.243 0.410
Commit [c] 355.852 15.880 -
Reveal [g] 205.656 5.659
Reveal [c] 351.192 8.514 -
Withdraw [g] 188.925 2.084
Withdraw [c] 336.533 4.490 -
SubmitWork [g] 197.399 6.537
SubmitWork [c] 368.948 13.116 -
TABLE I: Timing and transaction size of the AStERISK Chainspace smart contract (described in Section IV-A), measured over 10,000 runs. The transactions are independent of the number of authorities. The notation [g] denotes the execution the procedure and [c] denotes the execution of the checker. The Deposit function is not implemented as it is identical to the tumbler application described in Coconut [coconut].

We provide an open-source implementation444https://github.com/asonnino/coconut-chainspace of the AStERISK smart contract presented in Section IV-A for Chainspace [chainspace]. Our implementation does not enforce conditions on timers and as Chainspace currently does not provide functions to check block heights. We write our prototype in about 450 lines of Python code using an open source Python implementation of Coconut555https://github.com/asonnino/coconut, which reply on petlib666https://github.com/gdanezis/petlib and pblib777https://github.com/gdanezis/bplib; the bilinear pairing is defined over the Barreto-Naehrig curve888https://tools.ietf.org/id/draft-kasamatsu-bncurves-01.html, using OpenSSL as arithmetic backend. Table I provides the timing and transaction size for each function of the smart contract; each experiment is the result of 100 runs measured on a commodity laptop (a MacBook Pro 13’ 2.7 GHz Intel Core i7, running macOS Mojave). As expected, both the procedure and the checker of Create are extremely fast as they don’t involve cryptographic operations. The checker of Commit, Reveal, Withdraw, and SubmitWork take on average the same (and the longest) time as their core operation is to verify credentials validity; verifying credentials takes the longest time due to pairing operations [coconut]. The Deposit function is not implemented as it is identical to the tumbler application described in Coconut [coconut].

Viii Related Work

System Bids Privacy Bidders Privacy Bidders Non-Interactivity Distributed Authority Trusted Hardware Public Auditability
ShadowEth [yuan2018shadoweth]

Intel SGX [costan2016intel]
Hawk [kosba2016hawk]

None
Strain [blass2018strain]

None
Galal et al. [galal2018succinctly]

None
Bogetoft et al. [bogetoft2009secure]

None
Filecoin [filecoin]

None
AStERISK

None
TABLE II: Comparison security properties achieved by different systems discussed in this section. The decentralization property reads as follows;

: relies on a trusted 3 party,

: relies on a trusted 3 party for only one (or some) of the properties described in Section III,

: does not rely on any trusted 3 party.

There are several frameworks that target hiding private data submitted to a public ledger. Hawk [kosba2016hawk] divides Smart Contract into public and private parts and secure private input using zero-knowledge proofs, but requires a centralized trusted manager to operate. Furthermore, ShadowEth [yuan2018shadoweth] allows processing confidential Smart Contract data using Trusted Execution Environments (TEE). However, such a scheme requires users to trust the hardware vendor and can expose the system to TEE’s vulnerabilities [sgx_bad1, sgx_bad2]. On the subject of sealed-bid auctions, Blass and Kerschbaum [blass2018strain] proposed Strain, that preserve bids privacy against malicious participants. Strain uses a two-party comparison protocol, but has a flaw that reveals the order of bids. Furthermore, running protocols involving MPC on blockchain is not efficient due to extensive computations and the number of rounds involved. Furthermore, Galal and Youssef [galal2018verifiable] presented a protocol that ensures public verifiability, privacy of bids, and fairness. However, the solution scales badly with the number of bidders and relies on random number retrieved from blockchains that are not proven to be secure. This scheme was improved in [galal2018succinctly] using zk-SNARKS, but still relies on a centralized party for zero-knowledge proofs and does not protect bidders identity. An alternative approach was proposed by Bogetoft et al. [bogetoft2009secure]. The system uses a multiparty computation to perform auctions on encrypted bids. However, such a scheme reveals final assignment between bidders and object and lacks transparency. Currently, Filecoin [filecoin] does not implement an automated system assigning clients to storage nodes. Users are required to chose storage nodes manually and offers are publicly posted on the blockchain. Other industrial system such Golem [golem], iExec [iexec] or SONM [sonm] either do not specify their requester—worker assignment technique rely on similar, insecure solutions. All those platform could use AStERISK to increase their level of security and automatically determine optimal price for services. We summarize discussed solutions and their security features in Table II.

Ix Limitations

AStERISK inherits several limitations of Coconut which acts as the underlying credential scheme. These limitations are beyond the scope of this work, and deferred to future work. AStERISK is vulnerable if more than the threshold number of authorities are malicious; colluding authorities could create credentials to steal all the coins in the buffer of the smart contract. Note that bidders ’ privacy is still guaranteed under colluding authorities, or an eventual compromise of their keys.

The smart contract implementation of AStERISK described in Section IV-A does not scale to a large number of users as as each commitment and bid is kept on-chain. A potential solution is to defer the auction logic to state channel [miller2017sprites], and only seal the final result of the auction on the blockchain. Moreover, AStERISK inherits from any scalability limitation of the underlying smart contract platform.

The winner of the auction may invoke SubmitWork, but refuse to transfer data to the worker. This prevents the worker from claiming the reward and leave their resources unused until the next auction. This issue is inherited from Filecoin and can be mitigated with additional mechanisms assuring fair exchange of digital goods [dziembowski2018fairswap].

X Conclusion and Future Work

We presented AStERISK— a system for determining optimal prices for services in a shared economy environment and automatic assignments of requesters to the most optimal workers. AStERISK allows to securely perform sealed-bid auction on a blockchain using anonymous credentials and zero-knowledge proofs of knowledge. Our system allows workers to specify a minimal price for their services, protects users bids as well as the identity of the bidders. Contrary to the previous work, AStERISK does not rely on a trusted 3 party to issue credentials, but rather on a set of entities that can be freely chosen by users. The distributed authorities issue only partial credentials that are merged locally by each users protecting the system from a subset of malicious authorities. We showed how AStERISK can be deployed in the Filecoin network and adapted to other shared economy systems operating on blockchain. As a part of future work, we plan to extend our system to securely support requesters’ evaluation of multiple items and protect against data analysis attacks. Furthermore, we will investigate scalability of our solution with large networks and better integration with additional platforms.

Acknowledgements

Alberto Sonnino is supported by the EU H2020 DECODE project under grant agreement number 732546 as well as chainspace.io. Michał Król and Argyrios G. Tasiopoulos are supported by the EC H2020 ICN2020 project under grant agreement number 723014. Ioannis Psaras is supported by the EPSRC INSP Early Career Fellowship under grant agreement number EP/M003787/1.

References