AStERISK: Auction-based Shared Economy ResolutIon System for blocKchain
Alberto Sonnino, Michał Król, Argyrios G. Tasiopoulos, Ioannis Psaras
AAStERISK: Auction-based Shared EconomyResolutIon System for blocKchain
Alberto Sonnino
University College [email protected]
Michał Kr´ol
University College [email protected]
Argyrios G. Tasiopoulos
University College [email protected]
Ioannis Psaras
University College [email protected]
Abstract —Recent developments in blockchains and edge com-puting allows to deploy decentralized shared economy with utilitytokens, where altcoins secure and reward useful work. However,the majority of the systems being developed, does not providemechanisms to pair workers and clients, or rely on manualand insecure resolution. AStERISK bridges this gap allowingto perform sealed-bid auctions on blockchains, automaticallydetermine the most optimal price for services, and assign clientsto the most suitable workers. AStERISK allows workers to specifya minimal price for their work, and hide submitted bids as wellthe identity of the bidders without relying on any centralizedparty at any point. We provide a smart contract implementationof AStERISK and show how to deploy it within the Filecoinnetwork, and perform an initial benchmark on Chainspace.
I. I
NTRODUCTION
The cloud computing model developed during the last twodecades was built on the premise of compute centralization.That is, computing power is geographically and administra-tively concentrated in compute infrastructures of industrialscale, generally called datacenters. As a result, the majority ofusers currently rely on clouds for applications such as hostingservices, offloading computation, and data storage. However,centralization introduces several drawbacks; cloud computingservices act as large central points of failure [1], and makepossible for authorities to enforce censorship [2] or violate userprivacy [3]. Furthermore, large cloud operators often abusetheir market position to effectively force users to trust theirservice and adapt to operators’ rules and prices.Recent research efforts focus on shared-economy infras-tructures, where services are performed by users sharing theirresources with each other at the edge of the network [4].Such infrastructures can provide better quality of service,and reduce the exposure to central points of failures andabuse of power; but require security solutions and reliableincentive mechanisms to compensate the lack of trust betweendistributed users. Following the recent success of Bitcoin [5]a large amount of cryptocurrency projects implement such ashared economy model and use blockchains to secure theirplatforms and simplify payments [6], [7], [8], [9], [10], [11].The vision is to create a decentralized system, where users areincentivized to perform useful work and automatically receiverewards upon tasks completion.While multiple projects focus on the crucial task of provingto the network that a service has been successfully completed[12], [13], [14], [15], an equally important task of determiningan optimal price for those services has been largely ignored bythe community. Furthermore, industrial projects either do notcover this problem or rely on manual user interaction causing multiple scalability and security issues [6], [7], [8], [9]. In thiswork, we answer to the question of how blockchains and smartcontracts can be leveraged for deriving the price of a service indistributed computing infrastructures and automatically assignservice requesters to corresponding workers.
Clearly, the providers of the distributed infrastructure areexpected to ask for compensation, since admitting user requestswill impose operational expenses while occupying their per-sonal computing as well as storage resources. Therefore, thesufficient participation of infrastructure providers is associatedwith an incentivisation mechanism that allows them to profitby offering their resources at a price that equals or exceeds,their expenses. That is, the objectives of users and providersare conflicting with each other since the former try to accessa service at the lowest possible price while the latter try tomaximise their revenue. Therefore, there is a need for a marketmechanism that will intervene, in the form of an auction ,to ensure the effective association between user requests toproviders’ resources. By running auctions on blockchain, userdo not have trust each other nor any trusted 3 rd party, theyinherit security guarantees from the underlying distributedledger and can be sure that auction is performed correctlyusing Smart Contracts . However, data submitted to blockchainautomatically becomes public and in sealed-bid auctions itis 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 serversmakes the servers an easy target for malicious users willingthe bidder to lose their data.In this paper we propose AStERISK— an auction-basedshared economy resolution system running on top of dis-tributed ledger. In AStERISK, workers submit their offersto the blockchain together with a minimal price they arewilling to accept. Our system hides submitted bids and protectsbidders identity using anonymous credentials. In contrast torelated work, AStERISK does not rely on a single trusted3 rd party to issue all the credentials, but rather on a set ofmultiple, decentralised authorities. Each user can define theirown set trusted parties and is protected from a subset ofauthorities becoming malicious. Once an auction is finished,AStERISK automatically creates a binding on the blockchainallowing workers to claim money from requester deposits uponsubmission of a valid proof of useful work. For simplicity,we focus on the case of Filecoin [16], a decentralized storagenetwork, but AStERISK can be easily adapted to work withadditional systems implementing a shared economy model. a r X i v : . [ c s . CR ] J a n I. B
ACKGROUND a) Blockchain:
The blockchain technology [5] imple-ments a distributed, append-only ledger in the form of con-nected blocks; once information is stored in the blockchain itcannot be removed or altered. Network participants use a con-sensus protocol to agree on the current state of the ledger, andthe system maintains its properties as long as a subset of theparticipants is honest. Blockchains are used to record crypto-currencies ( e.g., , Bitcoin [5], Ethereum [17]) transactions. Acommon extension consisting of scripting languages enables toinclude logic as part of the transaction and allows deploymentof smart contracts—code submitted to the blockchain andexecuted by all network participants. AStERISK leverages thehigh-integrity data structure provided by blockchains, and usesit for accountancy, auditability, and time reference ( e.g., timemay be define as the block height of the main chain). b) Filecoin:
At the core of Filecoin lies a StorageMarket that allows requesters to pay miners, to store data.Specifically, a
Storage Market acts as an exchange pointwhere clients and miners can advertise their requests andoffer resources. The
Network guarantees that the miners arerewarded by the clients when providing the service. Filecoinuses Proof-of-Replication [15] a scheme that relies on zero-knowledge Succinct Non-interactive ARguments of Knowl-edge (zk-SNARKs) [18], [19] allowing a Prover to provepossession of data D . To prevent Sybil attacks and allowproving possession of multiple copies of the same file, Proofs-of-Replication are generated over a version of data encryptedunder a key ek specified by the requester such that R D ek = Encode ( D , ek ) . Filecoin requires the Prover to recursively andcontinuously generate those proofs with randomness r obtainedfrom the most recent block in the blockchain and thus provingpossession of the file over time. c) Anonymous Credentials: Anonymouscredentials [20], [21] allow the issuance of credentialsto users, and the subsequent unlinkable revelation to a verifier.Users can selectively disclose some of the attributes embeddedin the credential or specific functions of these attributes. Mostanonymous credentials scheme entrust a single authoritywith a master credential signature key, allowing a maliciousauthority to forge any credential. Other schemes do notprovide the necessary re-randomization or blind issuingproperties necessary to implement general purpose disclosurecredentials. To overcome these limitations, AStERISKrelies on Coconut [22] which supports distributed thresholdissuance of credentials; therefore supporting private attributes,re-randomization, and unlinkable multi-show selectivedisclosure without relying on a central trusted 3 rd party.Coconut is designed for use in the context of blockchainsto ensure confidentiality, authenticity and availability evenwhen a subset of credential issuing authorities are maliciousor offline; and uses short and computationally efficientcredentials that can easily be verified by a smart contract.Colluding authorities can forge Coconut credentials, butcannot break unlinkability and de-anonymize users. Coconutauthorities issue credentials without communicating with eachother, following a standard key distribution phase; as a result,a large number of authorities may be used to issue credentialswithout significantly affecting efficiency. III. D ESIGN G OALS
AStERISK associates worker resources to users via theexecution of an auction mechanism. Specifically, we considera system with the following actors: • Bidders - users willing to access a services ( e.g.,
Filecoinusers wishing to store some data in the network). • Workers - offer their services to the users ( e.g.,
Filecoinminers wishing to store users file for specific prices). • Authorities - distributed system responsible to issuecredentials allowing users to participate in auctions.AStERISK assumes that at least a threshold subset of theauthorities are honest; all cryptographic operations rely (or areimplied by) the XDH assumption [23]; and relies on weaksynchrony for liveness (but not for safety). These assumptionsare inherited from Coconut, and the underlying smart contractplatform. Given this threat model, AStERISK achieves thefollowing design goals: • Hidden Minimum Price:
Workers can specify a mini-mum price for which they are willing to perform givenactions, and are guaranteed that the winner of the auctionbids at least that price. This minimum price is kept privatefrom 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 theauction; bidders submit their bids without knowledge ofwhat other bidders do. • Bids Binding:
Bidders cannot change their bids once theyare committed. • Public Auditability:
Anyone can verify the correct exe-cution of any auction. • Fairness:
Bidders are financially penalized if they deviatefrom the protocol, but cannot be financially penalizedif they follow it correctly. Bidders cannot double-spendcoins [27], and no authority can steal bidder’s funds. • Non-Interactivity:
Bidders are not required to interactwith each other. • Censorship Resistance:
Anyone can act as bidder orworker; the system is resilient to censorship. • Distributed Authority:
AStERISK never relies on asingle trusted 3 rd party. • Auction’s economic properties:
Involving i ) Efficiency ,in terms of assigning resources to the bidders that valuethem the most in a computationally feasible way, ii ) Incentive Compatibility ( Truthfulness ), where bidders andworkers benefit by revealing their true valuations, iii ) Individual Rationality , where both bidders and workersare willing to participate, and iv ) Budget Balance , wherethe payments submitted cover workers’ compensations.IV. AS T ERISK D
ESIGN
A. AStERISK Smart Contract
We design AStERISK as a smart contract that extendsthe tumbler application of Coconut [22] to allow credentialsto be used as anonymous bids in auctions . The AStERISK Weak synchrony [24] is required by many smart contract platforms [25],[26], and by distributed key generation protocols required by Coconut [22]. The tumbler application is described at Section V.A of Coconut [22]. a) Preparation phase. (b)
Auction phase. (c)
Execution phase.
Fig. 1:
Overview of auction executions on AStERISK smart contract defines six functions (
Setup , Create , Deposit , Commit , Reveal , Withdraw ): (cid:118) Setup : A set of authorities jointly create an instance ofthe AStERISK contract by providing their public keys aswell as any other scheme parameters as the number ofauthorities and the threshold parameter. This function canbe run multiple time, and by different sets of authorities;the workers then select the set of authorities they trust uponexecuting
Create . (cid:118) Create : Any 3 rd party worker creates an auction byspecifying the set of authorities trusted to issue credentials,as well as any application specific parameter or policy. Theyalso specify, a commitment to the minimum price for whichthey are willing to operate; and two time-tamps , t commit and t reveal (where t commit < t reveal ) used during theauction phase (see Section IV-B). (cid:118) Deposit : Bidders deposit v coins into a buffer accountspecified by the smart contract to request a credential onthe public attribute v , and on a private randomly generatedsequence number s . To prevent tracing traffic analysis, v should be limited to a specific set of possible values,similar to cash denominations. Each authority monitors theAStERISK smart contract, and issue a partial credential tothe user—either on chain or off-chain—upon detecting acredential request (credential requests are processed only ifbidders paid a deposit of v coins to the smart contract).bidders locally aggregate all partial credentials into a con-solidated credential. (cid:118) Commit : Bidders submit a bid by showing a valid cre-dential to the smart contract; they also provides a proofof knowledge of the sequence number s along with agroup element ζ uniquely built from s . If the proof andthe credential check, the smart contract records ζ . Thegroup element ζ embeds the sequence number s and istherefore bound to the credential and the number of coins v it embeds—showing ζ effectively commits to v . The smartcontract accepts the bidders input only before t commit . (cid:118) Reveal : Bidders reveal v , ζ , and the credentials, as wellas a proof that v is correctly embedded in the credentialsand asserting correctness of ζ . The smart contract acceptsthe bidders input only after t commit and before t reveal , andif the smart contract previously recorded ζ ( i.e., if the biddercommitted to its bid). Workers open the commitment to theminimum price they committed to during Create . Time may be defined as the number of blocks built on top of the mainchain of the blockchain. (cid:118)
Withdraw : To withdraw the coins, the bidder providesthe smart contract with a zk-proof of knowledge of theirprivate key by binding the proof to the address addr where they wish to redeem the coins; they also providesthe consolidated credential, ζ , and a zk-proof attesting itscorrectness. To prevent double spending, the contract keepsa record of all group elements ζ that have already beenshown. Upon showing a ζ embedding a fresh (unspent)sequence number s , the contract verifies the credential andzero-knowledge proofs, and that ζ doesn’t already appear inthe spent list. Then, it withdraws v coins from the buffer andsends them to the specified address addr , and adds ζ to thespent list. Bidders can only withdraw coins after t reveal ,and only credentials that have been recorded by Commit and
Reveal can be used to withdraw coins (this effectivelylock the funds of bidders that deviate from the protocol).According to the policy set upon executing
Create , thewinner of the auction may be treated differently. (cid:118)
SubmitWork : After t reveal , the winner contacts theworker through a private channel, and uploads cryptographicmaterial to the smart contract allowing the worker to retrieveits payment. Winners can anonymously prove they actuallywon the auction by proving possession of the consolidatedcredential, ζ , and a zk-proof attesting its correctness. In thecase of Filecoin, the winner proves they won the auction tothe smart contract, and uploads a hash of the encrypted fileto store along with a signature. The file hash is then usedto verify Proofs of Spacetime [15] submitted by the workerand release payments from the bidder’s deposit over time. B. The AStERISK Protocol
Figure 1 shows the execution of an auction on AStERISK;the auction is divided in three phases: • Preparation phase (Figure 1a):
Bidders pay deposits andretrieve a credential required to participate in auctions,and storage nodes submit their offers. • Auction phase (Figure 1b):
Bidders commit and laterreveal their bids. The smart contracts determines thewinner by applying a Vickrey auction mechanism [28]. • Execution phase (Figure 1c):
Auction winner contactsits corresponding storage nodes, prove their identity andsubmit files to store. Storage node receives rewards forstoring files over time. a) Preparation phase:
A set of authorities executes the
Setup function of the AStERISK smart contract described inSection IV-A. Any worker executes
Create (Figure 1a- (cid:204) ) tocreate an auction by specifying the auction parameters, and3hich set of authorities they trust. They also specify the twotime-tamps, t commit and t reveal determining the auction’s timeline; workers advertise their product and provide a commitmentto a minimum price v at which they are willing to operate.Bidders execute Deposit by paying a deposits of v coins intoa buffer account specified by the AStERISK smart contract(Figure 1a- (cid:202) ), and retrieve a credential required to participatein auctions (Figure 1a- (cid:203) ). The value v represents the numberof coins they wish to bid. b) Auction phase: Bidders execute
Commit (Figure 1b- (cid:202) ) to commit to a bid for a particular auction on the smartcontract. Bidders commitments are only considered valid ifsubmitted before the deadline t commit . Next, workers openthe commitment to their minimum price, and bidders call Reveal (Figure 1b- (cid:203) ) to open their commitment to the smartcontract; bidders openings are valid only if submitted beforethe deadline t reveal . Finally (Figure 1b- (cid:204) ), the winner ofthe auction is deduced from the execution trace of the smartcontract. The group element ζ associated with the highest v (if v ≥ v ) indicates the winner of the auction—all biddersthat correctly followed the protocol (except the winner) maywithdraw their coins calling the Withdraw function of theAStERISK contract. If there is no winner, the auction fails andevery bidder may withdraw their money. AStERISK applies aVickrey auction mechanism [28]; the winner of the auctionis the bidder with the highest bid v , and pays the price ofthe second highest bid, v (cid:48) . That is, the winner is free to call Withdraw to withdraw ( v − v (cid:48) ) coins. c) Execution phase: The winning bidder execute
Sub-mitWork (Figure 1c- (cid:205) ) and submits hashes of the encryptedfiles to store. They then contact the corresponding worker off-chain, prove they are the rightful winner by showing theircredential, and directly transmits the file replica R D ek to theworker. The worker can then start generating proofs of usefulwork, submit them to the blockchain, and claim rewards fromthe winner’s deposit. Verifying the proof of useful work andreleasing the payment is an integral part of the underlyingblockchain, and is out of the scope of this work.V. D ISCUSSION
AStERISK involves worker specific contracts that offerresources in the form of a single item. In practice moresophisticated auctions are of interest where multiple workersoffer their resources in the form of multiple items while biddersexpress 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 shownthat combinatorial auction can be modelled as the set packingproblem, meaning that they are NP-hard and there is nopolynomial-time algorithm for finding the optimal allocation.A solution would be to consider a system where bidders areassociated into up to a single item. That would lead to acomputationally feasible and efficient assignment, i.e., multi-item unit demand auction [29] setting, on the expense howeverof bidders’ flexibility in expressing their preferences. On theother hand, the bidders are expected to submit a vector ofbids, i.e., one bid for each offered item. Although the Deposit function can be easily scaled up, i.e., by putting as a depositthe sum of bids or the maximum bid in a vector, the analysis of such vectors of bids could reveal information on the bidderandcreate a privacy challenge that has to be addressed.VI. P
ROTOCOL A NALYSIS
We argue how AStERISK achieves the design goals de-scribed in Section III. a) Hidden Minimum Price:
Upon the execution phaseof the auction, AStERISK guarantees that a worker will offertheir resources at a price higher than the minimum price ornot offer their resources at all. b) Bidders privacy:
AStERISK takes advantage of Co-conut’s unlinkability property to break the link between thedeposit of coins, the commit of bids, and the withdraw ofthe coins. As a result, bidders can submit bids on auctionswithout revealing their identity, yet proving possession of avalid credential. c) Bids privacy:
Bids are kept private until t commit ; thezero-knowledge property of Coconut credentials implies thatno information about v is revealed while committing to a bid(Figure 1b- (cid:202) ). d) Bids binding: Bidders are bound to their bids as theyare first required to commit to their bid (Figure 1b- (cid:202) ), andthen to open the commitment (Figure 1b- (cid:203) ). Bidders cannotopen the commitment to another value than the previouslycommitted as this implies forging the Coconut credentials. e) Public auditability:
AStERISK is implemented as asmart contract; its correct execution can be verified by any3 rd party by taking advantage of the public auditability of theunderlying smart contract plateform. f) Fairness: No single authority can create credentialsand steal all the coins in the buffer account of the smartcontract—the threshold property of Coconut implies that ad-versaries need to corrupt an arbitrarily large set of authoritiesfor this attack to be possible. Bidders cannot participate tothe auction phase (Figure 1b) without paying a deposit toreceive a valid credential; setting t commit < t reveal forces thebidders to commit to their bid before revealing it, preventingany 3 rd party from seeing other bidder’s bid before committingto a value. Bidders dropping out after committing a bid (andnever revealing it) are financially penalized as they cannotwithdraw their coins. Coconut provides blind issuance whichallows bidders to obtain a credential on the sequence number s without the authorities learning its value. Without blindness,any authority seeing s could potentially race the bidders,and withdraw the coins of the credential—blindness preventsauthorities from stealing the coins. Keeping a spent list ofall group elements ζ prevents double-spending attacks [27]without revealing the sequence number s ; this prevents anattacker from exploiting a race condition upon withdrawingand which may lock bidders coins. g) Non-interactivity: Bidders do not interact with eachother. During the preparation phase (Figure 1a), Bidders onlyinteract with a subset of the the authorities to receive acredential; during the auction phase (Figure 1b), they onlyinteract with the smart contract; during the execution phase(Figure 1c), bidders only interact with the workers or with thesmart contract to withdraw their coins. h) Censorship resistance:
The decentralized nature ofthe underlying smart contract platform makes the AStERISKsmart contract resilient to censorship. Furthermore, a small4
StERISK Chainspace smart contract
Operation µ [ms] √ σ [ms] size [kB] Create [g] 28.433 ± ∼ . Create [c] 0.0148 ± Commit [g] 194.243 ± ∼ . Commit [c] 355.852 ± Reveal [g] 205.656 ± ∼ . Reveal [c] 351.192 ± Withdraw [g] 188.925 ± ∼ . Withdraw [c] 336.533 ± SubmitWork [g] 197.399 ± ∼ . SubmitWork [c] 368.948 ± TABLE I:
Timing and transaction size of the AStERISK Chainspace smartcontract (described in Section IV-A), measured over 10,000 runs. The trans-actions are independent of the number of authorities. The notation [g] denotesthe execution the procedure and [c] denotes the execution of the checker.The
Deposit function is not implemented as it is identical to the tumblerapplication described in Coconut [22]. subset of authorities cannot block the issuance credentials—the service is guaranteed to be available as long as at least athreshold number of authorities are running. i) Distributed authority:
AStERISK introduce no sin-gle trusted 3 rd party; the AStERISK contract is executed ona decentralized smart contract platform, and Coconut allowsthreshold issuance of credentials. j) Auction’s economic properties: An auction satisfiesall those properties only under the condition of price-takerparticipants [30], i.e., both bidders and workers have no impacton the auction prices. In the single item auctions we considerhere, it has been proven that Vickrey auctions possesses allthese desired attributes based on the assumption of “sealedbids”, where neither bidders nor workers have informationabout the state of the auction [28]. AStERISK through itsprivacy properties provides a technical implementation of the“sealed bids” assumption which prevents price manipulations.VII. I
MPLEMENTATION & E
VALUATION
We provide an open-source implementation of theAStERISK smart contract presented in Section IV-A forChainspace [25]. Our implementation does not enforce con-ditions on timers t commit and t reveal as Chainspace currentlydoes not provide functions to check block heights. We writeour prototype in about 450 lines of Python code using anopen source Python implementation of Coconut , which replyon petlib and pblib ; the bilinear pairing is defined over theBarreto-Naehrig curve , using OpenSSL as arithmetic backend.Table I provides the timing and transaction size for each func-tion of the smart contract; each experiment is the result of 100runs measured on a commodity laptop (a MacBook Pro 13’ 2.7GHz Intel Core i7, running macOS Mojave). As expected, boththe procedure and the checker of Create are extremely fastas they don’t involve cryptographic operations. The checkerof
Commit , Reveal , Withdraw , and
SubmitWork take onaverage the same (and the longest) time as their core operationis to verify credentials validity; verifying credentials takesthe longest time due to pairing operations [22]. The
Deposit https://github.com/asonnino/coconut-chainspace https://github.com/asonnino/coconut https://github.com/gdanezis/petlib https://github.com/gdanezis/bplib https://tools.ietf.org/id/draft-kasamatsu-bncurves-01.html function is not implemented as it is identical to the tumblerapplication described in Coconut [22].VIII. R ELATED W ORK
There are several frameworks that target hiding private datasubmitted to a public ledger. Hawk [33] divides Smart Contractinto public and private parts and secure private input usingzero-knowledge proofs, but requires a centralized trusted man-ager to operate. Furthermore, ShadowEth [31] allows process-ing confidential Smart Contract data using Trusted ExecutionEnvironments (TEE). However, such a scheme requires users totrust the hardware vendor and can expose the system to TEE’svulnerabilities [37], [38]. On the subject of sealed-bid auctions,Blass and Kerschbaum [34] proposed Strain, that preservebids privacy against malicious participants. Strain uses a two-party comparison protocol, but has a flaw that reveals theorder of bids. Furthermore, running protocols involving MPCon blockchain is not efficient due to extensive computationsand the number of rounds involved. Furthermore, Galal andYoussef [39] presented a protocol that ensures public verifiabil-ity, privacy of bids, and fairness. However, the solution scalesbadly with the number of bidders and relies on random numberretrieved from blockchains that are not proven to be secure.This scheme was improved in [35] using zk-SNARKS, but stillrelies on a centralized party for zero-knowledge proofs anddoes not protect bidders identity. An alternative approach wasproposed by Bogetoft et al. [36]. The system uses a multipartycomputation to perform auctions on encrypted bids. However,such a scheme reveals final assignment between bidders andobject and lacks transparency. Currently, Filecoin [16] does notimplement an automated system assigning clients to storagenodes. Users are required to chose storage nodes manually andoffers are publicly posted on the blockchain. Other industrialsystem such Golem [6], iExec [8] or SONM [7] either donot specify their requester—worker assignment technique relyon similar, insecure solutions. All those platform could useAStERISK to increase their level of security and automaticallydetermine optimal price for services. We summarize discussedsolutions and their security features in Table II.IX. L
IMITATIONS
AStERISK inherits several limitations of Coconut whichacts as the underlying credential scheme. These limitations arebeyond the scope of this work, and deferred to future work.AStERISK is vulnerable if more than the threshold numberof authorities are malicious; colluding authorities could createcredentials to steal all the coins in the buffer of the smartcontract. Note that bidders ’ privacy is still guaranteed undercolluding authorities, or an eventual compromise of their keys.The smart contract implementation of AStERISK describedin Section IV-A does not scale to a large number of usersas as each commitment and bid is kept on-chain. A potentialsolution is to defer the auction logic to state channel [40],and only seal the final result of the auction on the blockchain.Moreover, AStERISK inherits from any scalability limitationof the underlying smart contract platform.The winner of the auction may invoke
SubmitWork , butrefuse to transfer data to the worker. This prevents the workerfrom claiming the reward and leave their resources unuseduntil the next auction. This issue is inherited from Filecoin5 ystem Bids Privacy Bidders Privacy Bidders Non-Interactivity Distributed Authority Trusted Hardware Public Auditability
ShadowEth [31] (cid:51) (cid:55) (cid:51)
Intel SGX [32] (cid:51)
Hawk [33] (cid:51) (cid:55) (cid:51)
None (cid:51)
Strain [34] (cid:51) (cid:55) (cid:55)
None (cid:51)
Galal et al. [35] (cid:51) (cid:55) (cid:55)
None (cid:51)
Bogetoft et al. [36] (cid:51) (cid:55) (cid:51)
None (cid:55)
Filecoin [16] (cid:55) (cid:55) (cid:55)
None (cid:51)
AStERISK (cid:51) (cid:51) (cid:51)
None (cid:51)
TABLE II:
Comparison security properties achieved by different systems discussed in this section. The decentralization property reads as follows; : relieson a trusted 3 rd party, : relies on a trusted 3 rd party for only one (or some) of the properties described in Section III, : does not rely on any trusted3 rd party. and can be mitigated with additional mechanisms assuring fairexchange of digital goods [41].X. C ONCLUSION AND F UTURE W ORK
We presented AStERISK— a system for determining op-timal prices for services in a shared economy environmentand automatic assignments of requesters to the most optimalworkers. AStERISK allows to securely perform sealed-bidauction on a blockchain using anonymous credentials and zero-knowledge proofs of knowledge. Our system allows workers tospecify a minimal price for their services, protects users bidsas well as the identity of the bidders. Contrary to the previouswork, AStERISK does not rely on a trusted 3 rd party to issuecredentials, but rather on a set of entities that can be freelychosen by users. The distributed authorities issue only partialcredentials that are merged locally by each users protectingthe system from a subset of malicious authorities. We showedhow AStERISK can be deployed in the Filecoin networkand adapted to other shared economy systems operating onblockchain. As a part of future work, we plan to extend oursystem to securely support requesters’ evaluation of multipleitems and protect against data analysis attacks. Furthermore,we will investigate scalability of our solution with largenetworks and better integration with additional platforms.A CKNOWLEDGEMENTS
Alberto Sonnino is supported by the EU H2020 DECODEproject under grant agreement number 732546 as well as chainspace.io . Michał Kr´ol and Argyrios G. Tasiopoulosare supported by the EC H2020 ICN2020 project under grantagreement number 723014. Ioannis Psaras is supported by theEPSRC INSP Early Career Fellowship under grant agreementnumber EP/M003787/1.R
EFERENCES[1] J. Swearingen, “http://nymag.com/selectall/2018/03/when-amazon-web-services-goes-down-so-does-a-lot-of-the-web.html,” 2018.[2] A. Glaser, “How apple and amazon are aiding chinese censors,” 2018.[3] B. Debatin, J. P. Lovejoy, A.-K. Horn, and B. N. Hughes, “Facebookand online privacy: Attitudes, behaviors, and unintended consequences,”
Journal of computer-mediated communication , vol. 15, no. 1, pp. 83–108, 2009.[4] N. Abbas, Y. Zhang, A. Taherkordi, and T. Skeie, “Mobile edgecomputing: A survey,”
IEEE Internet of Things Journal , vol. 5, no. 1,pp. 450–465, 2018.[5] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.[6] T. G. Project, “Golem whitepaper.” https://golem.network/doc/Golemwhitepaper.pdf, 2016.[7] “Sonm documentation.” https://docs.sonm.com/, 2018. [8] “iexec whitepaper.” https://iex.ec/whitepaper/iExec-WPv3.0-English.pdf, 2018.[9] A. Angelo, P. Thellmann, and D. Dalkilic, “Rewarding the tokeneconomy..” https://bounty0x.io/whitepaper en.pdf, 2018.[10] Y. Combinator, “Ipfs, coinlist, and the filecoin ico with juan benet..”[11] P. Labs, “Proof of replication technical report,” tech. rep., 2017.[12] M. Al-Bassam, A. Sonnino, M. Kr´ol, and I. Psaras, “Airtnt: Fairexchange payment for outsourced secure enclave computations,” arXivpreprint arXiv:1805.06411 , 2018.[13] M. Kr´ol and I. Psaras, “Spoc: Secure payments for outsourced com-putations,”
Proc. NDSS Workshop on Decentralized IoT Security andStandards, San Diego, CA , 2018.[14] A. Miller, A. Juels, E. Shi, B. Parno, and J. Katz, “Permacoin: Repur-posing bitcoin work for data preservation,” in , pp. 475–490, IEEE, 2014.[15] J. Benet, D. Dalrymple, and N. Greco, “Proof of replication,” tech. rep.,Technical report, Protocol Labs, July 27, 2017. https://filecoin. io/proof-of-replication. pdf. Accessed June, 2018.[16] P. Labs, “Filecoin: A decentralized storage network,” tech. rep., 2018.[17] V. Buterin et al. , “Ethereum white paper,” 2013.[18] R. Gennaro, C. Gentry, B. Parno, and M. Raykova, “Quadratic spanprograms and succinct nizks without pcps,” in
Annual InternationalConference on the Theory and Applications of Cryptographic Tech-niques , pp. 626–645, Springer, 2013.[19] E. Ben-Sasson, A. Chiesa, D. Genkin, E. Tromer, and M. Virza, “Snarksfor c: Verifying program executions succinctly and in zero knowledge,”in
Advances in Cryptology–CRYPTO 2013 , pp. 90–108, Springer, 2013.[20] M. Chase, S. Meiklejohn, and G. Zaverucha, “Algebraic macs andkeyed-verification anonymous credentials,” in
Proceedings of the 2014ACM SIGSAC Conference on Computer and Communications Security ,pp. 1205–1216, ACM, 2014.[21] D. Pointcheval and O. Sanders, “Short randomizable signatures,” in
Cryptographers’ Track at the RSA Conference , pp. 111–126, Springer,2016.[22] A. Sonnino, M. Al-Bassam, S. Bano, and G. Danezis, “Coconut:Threshold issuance selective disclosure credentials with applications todistributed ledgers,” arXiv preprint arXiv:1802.07344 , 2018.[23] D. Boneh, B. Lynn, and H. Shacham, “Short signatures from the weilpairing,” in
International Conference on the Theory and Application ofCryptology and Information Security , pp. 514–532, Springer, 2001.[24] M. Castro, B. Liskov, et al. , “Practical byzantine fault tolerance,” in
OSDI , vol. 99, pp. 173–186, 1999.[25] M. Al-Bassam, A. Sonnino, S. Bano, D. Hrycyszyn, and G. Danezis,“Chainspace: A sharded smart contracts platform,” arXiv preprintarXiv:1708.03778 , 2017.[26] E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, andB. Ford, “Omniledger: A secure, scale-out, decentralized ledger viasharding,” in ,pp. 583–598, IEEE, 2018.[27] G. O. Karame, E. Androulaki, and S. Capkun, “Double-spending fastpayments in bitcoin,” in
Proceedings of the 2012 ACM conference onComputer and communications security , pp. 906–917, ACM, 2012.[28] W. Vickrey, “Counterspeculation, auctions, and competitive sealed ten-ders,”
The Journal of finance , vol. 16, no. 1, pp. 8–37, 1961.
29] T. Andersson and A. Erlanson, “Multi-item vickrey–english–dutchauctions,”
Games and Economic Behavior , vol. 81, pp. 116–129, 2013.[30] R. B. Myerson and M. A. Satterthwaite, “Efficient mechanisms forbilateral trading,”
Journal of economic theory , vol. 29, no. 2, pp. 265–281, 1983.[31] R. Yuan, Y.-B. Xia, H.-B. Chen, B.-Y. Zang, and J. Xie, “Shadoweth:Private smart contract on public blockchain,”
Journal of ComputerScience and Technology , vol. 33, no. 3, pp. 542–556, 2018.[32] V. Costan and S. Devadas, “Intel sgx explained.,”
IACR CryptologyePrint Archive , vol. 2016, no. 086, pp. 1–118, 2016.[33] A. Kosba, A. Miller, E. Shi, Z. Wen, and C. Papamanthou, “Hawk:The blockchain model of cryptography and privacy-preserving smartcontracts,” in ,pp. 839–858, IEEE, 2016.[34] E.-O. Blass and F. Kerschbaum, “Strain: A secure auction forblockchains,” in
European Symposium on Research in Computer Se-curity , pp. 87–110, Springer, 2018.[35] H. S. Galal and A. M. Youssef, “Succinctly verifiable sealed-bid auctionsmart contract,” in
Data Privacy Management, Cryptocurrencies andBlockchain Technology , pp. 3–19, Springer, 2018.[36] P. Bogetoft, D. L. Christensen, I. Damg˚ard, M. Geisler, T. Jakobsen,M. Krøigaard, J. D. Nielsen, J. B. Nielsen, K. Nielsen, J. Pagter, et al. ,“Secure multiparty computation goes live,” in
International Conferenceon Financial Cryptography and Data Security
International Conference on Financial Cryptographyand Data Security, Trusted Smart Contracts Workshop. Springer , 2018.[40] A. Miller, I. Bentov, R. Kumaresan, and P. McCorry, “Sprites: Paymentchannels that go faster than lightning,”
CoRR abs/1702.05812 , 2017.[41] S. Dziembowski, L. Eckey, and S. Faust, “Fairswap: How to fairlyexchange digital goods,” in
Proceedings of the 2018 ACM SIGSACConference on Computer and Communications Security , pp. 967–984,ACM, 2018., pp. 967–984,ACM, 2018.