Verifiable and Auditable Digital Interchange Framework

01/11/2020 ∙ by Prabal Banarjee, et al. ∙ 0

We address the problem of fairness and transparency in online marketplaces selling digital content, where all parties are not actively participating in the trade. We present the design, implementation and evaluation of VADER, a highly scalable solution for multi-party fair digital exchange that combines the trusted execution of blockchains with intelligent protocol design and incentivization schemes. We prototype VADER on Hyperledger Fabric and extensively evaluate our system on a realistic testbed spanning five public cloud datacenters, spread across four continents. Our results demonstrate that VADER adds only minimal overhead of 16 solution, while significantly outperforming a naive blockchain based solution that adds an overhead of 764



There are no comments yet.


page 1

page 2

page 3

page 4

This week in AI

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

1. Introduction

Online media consumption is a big business (79), with users watching billions of hours of videos per month (YouTube, 2019) and media traffic constituting roughly 70% of downstream internet traffic  (Sandvine, 2018).

A key reason for this success, lies in the simplicity of present day online media (and money) exchange process as depicted in Fig. 1. As shown, a present day content creator can simply upload content and get paid based on viewership (or sales). Similarly, buyers can pay the right price to access media without worrying about content authenticity, price gouging, non delivery etc. The ease of operation is due to presence of facilitators such as Youtube, Netlflix, iCloud etc. As shown in Fig. 1, the facilitator provides all the ancillary but critical services of content hosting, searching, delivery, payments etc. to complete the digital ecosystem for online media consumption. While the efficacy of present day media delivery systems is reflected in their success, they suffer from an important shortcoming in the inability to guarantee honest behavior and vulnerability to fraudulent behavior by participants. This is due to the fact that present day systems lack the underpinnings to demonstrably guarantee honest behavior; forcing both buyers and owners to trust that a facilitator behaves in a fair manner.

Figure 1. Present day video exchange

For example in Fig. 1, the owner trusts the facilitator to honestly report the number of views/downloads and calculate its royalty payments in a transparent manner. Similarly, the buyer trusts the facilitator to deliver the right content against payment. Finally, the facilitator expects the buyer to pay for a successful delivery, without falsely alleging non-delivery.

However, lack of baked-in guarantees of honest behavior can lead to disputes, such as a buyer fraudulently alleging non-receipt of content and denying payments thus stealing content from facilitator; facilitator mis-reporting sales to cheat owner of dues, or even charging buyers without providing right content.

In fact, recent events highlight the inadequacy of this trust based model (86; 90; A. C. to the YouTube Partner Program (YPP) to Better Protect Creators (2018)). Specifically, content owners have raised a number of complaints against faclitators regarding their royalty earnings and lack of clarity in the calculation (61; L. Marshall (2015); 87), highlighting discrepancies in earnings with reported viewership. Similarly, buyers have also raised disputes regarding content received from these platforms (6).

We believe that such disputes can only increase in future to the detriment of the growth of online media delivery platforms. This in turn, motivates us to address this important problem of guaranteeing successful video exchange amongst mutually untrusting buyers and facilitators. We ensure each party (owner, buyer and facilitator) gets their rightful outcome or no one does. We define the above as Multi-party fair digital exchange (abbreviated as fair exchange in the rest of the paper) among the owners, buyers and facilitators in the marketplace model.

Note that prior work (Bhagwan et al., 2014; Haeberlen et al., 2010, 2007) for providing fairness are not applicable in the above setting as they trust the facilitator to grant access to internal logs and metrics, an important assumption we intend to avoid. Similarly, decentralized video delivery platforms (LBRY, 2019; Livepeer, 2019; Vivuly, 2019; BitTube, 2019; DTube, 2019) which bypass centralized facilitators (thus obviating the need to trust them), while promising are not suitable. This is due to the fact that decentralized content delivery platforms suffer from poor content quality, sporadic availability, rampant illegal content etc., ironically due to absence of a facilitator’s dedicated resources in maintaining the platform (Adhikari et al., 2012a).

Motivated by above observations, we set our goal to develop a readily usable solution for fair exchange, which would be a)compatible and incrementally deployable with present day facilitator driven marketplace systems and b) should be able to provide transparency and fairness into existing video delivery platforms with minimal overhead in terms of modifications and performance.

In this paper we present the system design, implementation and evaluation of Verifiable and Auditable Digital Interchange Framework (VADER) which satisfies the above mentioned criteria.

In process of designing VADER, we study various fraud risks that arise in the marketplace model and note that guaranteeing multi-party fair exchange in this model presents a unique challenge. As shown in Fig. 1, the owner is a passive party, in the sense that after video upload, it is not directly involved in the exchange of video and money between the active parties viz. the facilitator and buyer. Being a passive party, an owner is completely dependent on the honesty of facilitator, as it has no way to learn of exchanges of its content being done. This makes the owner vulnerable to being misled about its true earnings, either by the facilitator (61) alone, or in collusion with the buyer (6; 60). Fig 1, highlights the specific risks faced by the respective parties.

We note that while the problem of fair exchange among active parties is well studied in theory (Rabin, 2005; Goldreich et al., 1987; Yao, 1986; Pagnia and Gärtner, 1999); to the best of our knowledge, protecting rights of passive parties, without significantly altering the flow of video exchange 111i.e., without making owner also an active party by say asking for its approval on every trade is a new paradigm for fair exchange, not yet covered in literature.

In VADER we not only protect the buyer and facilitators against various active party risks but secure owner’s interest from passive party risks. To the best of our knowledge, VADER is the first real system to demonstrate such capabilities.

VADER accomplishes low overhead fair exchange solution by leveraging the following key insights,
Insight 1) We can guarantee fair exchange by sending encrypted video and performing fair exchange of only the key and money. This enables us to leverage the existing optimized delivery infrastructures of facilitators for sending (encrypted) content and making system for fairness incrementally deployable.
Insight 2) By assuming the presence of a trusted arbitrator that is slow (when compared to direct interaction without intermediary) but can deterministically detect a malicious party and provide restitution (right encrypted content, key or money) to the honest party, parties can opportunistically exchange key and money directly between themselves without having to interact with the arbitrator unless there is a dispute.
Insight 3) Assuming parties are rational, introduction of bounties (that are large and funded by penalizing malicious parties) for reporting misbehavior introduces an element of distrust between parties, thus preventing collusion aimed at subverting the protocol. Note that, the first two insights enable efficient operation, guaranteeing fairness for the active parties; while the third insight ensures fairness for the passive party under assumption of rational participants.

We select blockchain as the tamper-proof ledger and execution platform for VADER. Our selection of blockchain is motivated by the fact that it offers decentralization of trust and auditability guarantees sought by VADER. Furthermore, the native blockchain cyptocurrency can be used to design incentivization schemes and programmatically enforce desired behavior from the interacting parties as mandated by our insights above. We also point out the second insight of opportunistic exchanges on fast path (batching), while reverting to the slow but guaranteed path is also used in state-channels for scaling transaction throughput. However, these solutions involve native assets such as cryptocurrencies giving complete control to the arbitrator to revert back the state (e.g. ownership) of an asset. On the other hand, we deal with non-native assets such as decryption keys which once delivered to the buyer are unaffected by blockchain asset state. We modify the state-channel protocol to account for the above oddity, as described in Sec. 3.1.

As part of this work, we have systematically studied exchange process in present day video delivery platforms and used the insights to design and implement VADER. VADER protocol carefully combines insights from diverse domains of cryptography, incentives design, blockchains to ensure fair exchange for video exchange. VADER is incrementally deployble with minimal modifications to present day video delivery platforms. Specifically, in Sec. 3 we design VADER protocol (message exchange sequence) and perform a comprehensive security analysis to show how VADER protects honest parties against attacks in Sec. 3.4. We implement VADER incorporating all the insights described above and extensively study the performance of VADER over two baseline techniques, through extensive evaluation across realistic workloads.

We note that while we use video as an example digital asset in this paper, VADER works for any digital content (74; 27; 33; 75) that can be provably verified, say using cryptographic digests. Additionally, the owner in VADER is a logical abstraction that can represent multiple entities that need to be paid royalties individually, as in the music industry (Marshall, 2015). Finally, VADER focuses on guaranteeing fair exchange between the buyer, facilitator and owner. VADER does not address the complementary issue of content piracy, where a buyer buys content legally on a VADER based marketplace and then resells it with minor modifications. Other works (H. Sivonen (2013); 84), including recent work (Mangipudi et al., 2018) use a combination of content watermarking and on-blockchain penalty mechanisms to prevent content piracy which can be easily embedded into VADER smart contracts.

We believe that fair exchange systems will be the norm in near future and our work advances the nascent area of designing practical systems for Multi-Party Fair exchange. We claim the following as key contributions: 1) To the best of our knowledge, we are the first to formulate and present the problem of multi-party fair digital exchange in third party marketplace scenario where one of the parties is passive and does not directly interact with the buyer (Sec. 1 & 2). 2) We design the VADER protocol and study its security properties. 3) We implement VADER protocol on Hyperledger Fabric, and extensively evaluate its performance on a realistic test-bed of upto 91 nodes spread over 4 continents, transferring at least 50TB of data over the network. We find that VADER adds only minimal overhead of 16% in median case compared to the baseline VANILLA solution.

Outline: The rest of the paper is organized as follows. In Sec. 2, we formally describe the problem and the solution requirements. In Sec. 3, we describe our solution and discuss the security analysis of our work in Sec. 3.4. We present details of VADER implementation in Sec. 4 and in Sec.5, we present performance evaluation of VADER under realistic conditions. In Sec. 6, we discuss the related work and finally conclude our paper in Sec. 7

2. Problem Setup

We define Owner () as a party, such as artists or financiers, that need to be monetarily compensated for every successful trade/download of the digital content. We define Facilitator() as a party responsible for conducting the trade on behalf of . Finally, we define a Buyer() as a party that is buying digital content from ’s marketplace.

As explained in Sec. 1,  is the passive party while  and  are active parties in the digital exchange. Further, we assume the parties do not completely trust each other and  and  do not know each other. We also assume that the parties are rational and will collude with each other to maximize profit.
A Multi-party Fair Digital Exchange protocol in the above context, should ensure that either all parties receive their desired item in exchange for their own item/service, or none of the parties receive anything. Specifically, Multi-party Fair Digital Exchange guarantees the following behavior: a) A  will always get the correct video uploaded by  if it can submit proof of payment b) A  will always get paid if it can submit evidence of sending the correct video c) An  will always get paid if  was paid by selling its content.

Attacks: A fair exchange protocol for video delivery must protect against the following attacks: Atk.1- Royalty Manipulation: constitutes any manipulation in the royalty calculation of  e.g. a malicious  can cheat  by a) misreporting the number of downloads or b) selling the content to  at a higher price while compensating  with a lower royalty by exploiting the information asymmetry between  and . Atk.2- Content Mismatch: constitutes delivery of content to a  that is different from the one promised while receiving money. Atk.3- Content Stealing: constitutes gaining access to the content without compensating the designated parties for their fair share of payment for the same, e.g.  getting access to content without paying money to  by claiming to have received wrong content despite getting right content, thus cheating both  and .

Under our threat model, the above attacks represent a completely exhaustive list of attacks on marketplace fairness. We reiterate that VADER does not address the complementary issue of content piracy, and is compatible with other solutions (H. Sivonen (2013); 84; E. V. Mangipudi, K. Rao, J. Clark, and A. Kate (2018)) that address piracy.

Figure 2. Video exchange lifecycle in VADER
Figure 3. VADER message exchanges

3. Solution Description

We describe VADER protocol by presenting an outline of the solution in Sec. 3.1 and the details of various protocol steps in Sec. 3.2. We also, present a security analysis of our protocol in Sec. 3.4.

Notation: We use the following notation in the description of our solution. Let be a security parameter, be a cryptographically secure hash function, (, , ) be a IND-CCA secure symmetric encryption scheme and (, , ) be a public key cryptosystem based secure digital signature scheme. We assume that at bootstrap, each party generates a key pair using . We use  to represent the distributed blockchain ledger and  to represent a state channel between two parties.

1:function OpenEscrow()
2:  if  then
6:   return   
7:function ()
8:  if AND
9:    ) then
10:  for each  do
11:    -=
13:function ()
14:  if  then
Algorithm 1 Conditional Escrow Contract

 represents the settlement timeout

1:function Open(,,,,,,)
3:  .
5:  ..,
6:  ..,
7:  , = ,
8:  .Store()
9:function Close(,)
10:  if . AND
11:    return
12:  for each  do
16:  .Store(.)
17:function settleChannel()
18:  if . AND
20:  .Store()
Algorithm 2 State Channel Contract

3.1. Solution Outline

VADER aims to deliver an efficient solution for guaranteeing fair exchange by leveraging the three insights described in Sec. 1. Following the first insight,  utilizes its usual content delivery infrastructure to send encrypted video to   thereby reducing the problem of fair video exchange to that of fair exchange of key and money.

Fig. 3 depicts the phases of video exchange using VADER. In the Initialization phase, leveraging the second insight,  and  lock money in the blockchain escrow to create a channel, akin to state-channels (Poon and Dryja, 2016; Dziembowski et al., 2018b). We define channel as a unique bi-directional message queue between two parties, backed with blockchain escrowed money, enabling parties to conduct multiple exchanges directly without hitting blockchain (Channel construction and lifecycle described later). This money is then used as collateral in the Exchange and Finalization phases where the  and  exchange money and video directly offchain. Finally, in the Penalization and Settlement phase, disputes, if any, are resolved deterministically by the trusted arbitrator on-chain as shown in Fig. 3 and escrow money appropriately redistributed to  and . We note that, as shown in Fig. 3 only Initialization and Settlement phases interact with blockchain, while exchange and finalization phases are executed directly between  and  without hitting the blockchain. Moreover,  being the passive party does not have any actions during the exchange and finalization steps of the protocol.

VADER leverages the trusted execution of a suite of blockchain deployed smart contracts, to emulate a trusted arbitrator. The trusted arbitrator (in settle phase) works as follows: 1) Any party can close the channel either due to dispute or logical end of application exchange, and submit evidence of protocol compliant behavior to the smart contract, if any 2) VADER allows the counterparty to submit counterfactual evidence within a pre-determined time period to state its view of the offchain protocol state. As shown in Fig. 3, the VADER smart contracts evaluate the evidence submitted by both parties and then either transfer money to  (refund) or  (payment) from an escrow that is funded in the initialization phase.

Finally, motivated by the third design insight, VADER protocol design introduces a bounty scheme that rewards  with a much larger monetary benefit, by penalizing  (compared to cost of the video) if it can submit evidence of cheating by  to the arbitrator. As mentioned before, under assumptions of rationality, the penalty scheme prevents collusion between  and  in which they both agree to alter the offchain message exchanges between themselves for mutual benefit (by dividing ’s share between themselves), and submit the altered sequence in the settlement phase, thereby cheating  of its fair share. By making it more beneficial for  to report  and collect bounty, in turn, forcing  to honestly report exchange information to the arbitrator, VADER ensures the passive party, , gets its rightful share. Finally, we note that VADER uses two well known constructs described below.

Evidence of protocol compliance: VADER leverages cryptographic commitment schemes and digital signatures over messages exchanged between  and  as evidence of protocol compliant behavior by blockchain based trusted arbitrator.

Conditional Escrow: This construct allows parties to prove solvency to each other as the first step of digital exchange by locking money on blockchain and guaranteeing that the money cannot be unilaterally withdrawn by either party. This construct is used by the trusted arbitrator to lock money (crypto-currency) for a duration () in the initialization phase and deterministically release money () based on submission of evidence () for VADER protocol compliant operation in settle phase. Alg. 1, shows a conditional escrow contract, wherein an entity can lock money(), for a duration of time(). Money() is releasable before only on successful evaluation of condition . Alg. 1 in Appendix shows pseudocode for conditional escrow contract.
Our state channel construction builds on top of the conditional escrow contract. In Alg. 2 we provide our state channel algorithm providing open, close and settle semantics. In addition to the one’s in Alg. 2 our state channel supports the following properties (used in subsequent algorithms), 1) .Store and .Load:- which is the per party local channel storage where each party can save messages, 2) .Send and .Recv:- using which one party can send a message to the other party involved in the state channel.

3.2. Solution Description

As mentioned in Sec. 3.1, VADER proceeds in the four phases as depicted in Fig. 3. We describe the specifics of each of the phases next.

% Royalty  should receive per Xchg

1:function .UpContent()
5:  Send ¡, , = (,)¿ to  
6:  Receive from
1:function .RecvContent()
2:  On Recv from
3:  if  then
4:   terminate   
7:  if ( then
8:   terminate   
11:  .
12:  Send to
Algorithm 3 Content Registration

The content which  is requesting

Bid price  wants to pay

Ask price which  wants

1:function .ContentReq(, )
2:  ;
4:  ;
5:  . to ;
6:   is generated in ServContentReq
7:   = .() from
8:  .() 
1:function .ServContentReq(, , )
2:   = .() from
3:  if  then
4:   .  
6:  if  then
7:   .  
8:  if ( is prev. known in then
9:   .  
12:  .() to
13:  .() 
Algorithm 4 Trade Agreement

Phase 1: Initialization: This phase involves  uploading content to the  and  setting up a channel to be used for multiple exchanges with .
Init.1  -  Content Registration: As shown in Alg 3, Owners register their content for sale in the marketplace by uploading the content (=) composed of chunks along with its digest =,, and , the percentage to be given to  for each sale of (for privacy reasons is encrypted with the public key of ). On receiving ,  verifies the message signature and records  as the unique owner and  as an authorized distributor on blockchain. Note that content registration is a one time operation between the  and . At the end of this step, the rightful ownership of video content is established on blockchain.

Init.2  -  Channel Creation: During initialization,  funds the channel (with ) with crypto-currency (sufficient for multiple video exchanges) by locking money in an on-chain escrow. Similarly,  also makes an initial deposit, that is much larger compared to ś deposit (to cover penalties described later). Once both deposits are committed to blockchain, the state channel contract generates a unique channel id that is used to bind subsequent message exchanges between  and  to the channel.
Phase 2: Exchange: The exchange phase is the core of VADER, as shown in Fig.3, where  and  perform exchange of the digital content. Fig. 3 shows the messages used in the construction of VADER exchange protocol as described below.

Timeout  uses waiting for enc. content

1:function .SendContent(, )
5:  .() to
6:   = .() from
9:  .() to
10:  .() 
1:function .RecvContent(, )
2:   .() from
3:  Save
5:  for each  do
6:   if  then
7:     Request  for correct
8:     Start timer ; On Timeout:
9:       if correct chunk is received within
10:         Update
11:       else
12:          Matching chunk & hash is not received
13:         .       
15:  .() to
16:   is generated in SendContent
17:   = .() from
18:  .() 
Algorithm 5 Offline Video Exchange &  Ack

Timeout  uses waiting for

1:function .SendIOU(, )
4:  . : 
5:      Start timer ; On Timeout:
6:          if is not received then
7:               .
8:   .() from
9:  .
10:  .()
1:function .SendKey(, )
2:   = .() from
3:  if  then
4:   .    
5:  if  then
6:   .    
7:  if  then
8:   .    
10:  .() to
11:  .()
Algorithm 6 Exchange
1:function .DecryptAndVerify(, )
5:  for each  do
6:   if  then
7:      Collect dispute evidence from channel
9:     .
12:  Everything OK. Continue Trade
Algorithm 7 Decrypt And Verify

Xchg.1 Exchange Agreement: The goal in this step is to ensure that both  and  mutually agree on the video to be exchanged and the price to be paid by  to . As depicted in Alg 4,  submits to   the Exchange Request message, , (m=¡, , , ¿, ), containing the channel id , video identifier , a randomly generated, strictly monotonically increasing , as well as the amount that  agrees to transfer on successful exchange. On receiving ,  checks that the is indeed monotonically increasing, to ensure is not reused (explained later in penalization scheme), and the transfer price is agreeable. In return,  sends counter-signed message = ¡,¿ to , committing to the terms.
Xchg.2 Out-of-Band Encrypted Video Transfer: Next, based on insight 1, as depicted in Alg 5  randomly samples key and sends encrypted version of the requested video along with signed hashes of each individual encrypted chunk
={ } in to .
On receiving encrypted video,  verifies if the digest matches with the one sent by  in . In case of a match,  sends counter signed Encrypted Video Acknowledgement in ¿. In case of a digest mismatch,  requests  for retransmission of specific chunks until either agreement is reached or failure after certain number of retries. In the next step,  and  exchange key and money in a trustworthy manner.
Xchg.3 Money-Key Exchange: In this step, as shown in Alg 6,  1) sends an optimistic IOU message to , and 2) starts a timer within which  needs to send the key . In case of timeout,  closes the channel and initiates dispute resolution. On receiving the IOU,  releases the key along with digest in .
Phase 3: Finalization: In this phase,  verifies whether it received the right content or raises a dispute.
Final.1 Verification: As shown in Alg 7,  decrypts the video using and verifies that )} matches uploaded by . In case of match,  has received desired content and the same channel can be re-used for future exchanges. However, in case of a mismatch, i.e.  sent wrong content,  closes the channel and registers a dispute with the Dispute Resolve smart-contract by submitting as evidence along with at least one of the mismatched chunks, .
Final.2 Channel Balance Update: At the end of a successful exchange, each party locally updates the channel balance of the counterparty and decides if the channel has sufficient balance to continue or must be closed.
As shown in the Fig. 3, in both phase 2 & 3,  &  do not interact with blockchain and carry out opportunistic exchanges (based on insight 2).

Dispute evidence

1:function RaiseDispute(, , )
4:  if  is or (  then
5:   Start timer ; On Timeout:
6:   if (No from  within ) OR 
7:     ( gives but ( )
8:        goto ReturnMoneyTo    
10:  if  then
11:     Cheated, No Loss to  
12:   return
13:  else   Cheated.   
14:     . -=
15:     . +=
Algorithm 8 Dispute Resolve Smart Contract

Phase 4: Settlement: At the end of multiple exchanges,  and  submit all their offchain state to blockchain smart contracts (trusted arbitrators) to settle channel balance, resolve disputes and automatically pay  based on the number of successful exchanges.
Settle.1 Channel Closure and Settlement: Akin to state-channels, VADER channel closing semantics guarantee that once a party closes the channel, the other party has up to time to submit its set of offchain signed messages as evidence to the channel settlement smart contract. After time , the smart contract verifies the validity of each offchain message sequence and first settles the successful exchanges by transferring money worth to  and to  from channel escrow. Disputes are settled as described next.

Settle.2 Dispute Resolution: In case of a dispute raised by   the Dispute Resolve Contract Alg. 8 performs two steps to identify the faulty participant as described below 1) In line 4, it encrypts the disputed chunk with key (if present) and checks if the hash of the encrypted chunk matches the one agreed by  in . In case of key not released dispute by ,  has time within which to submit . 2) In line 10, it computes hash of the chunk and checks if it matches with the hash registered by  in Init.1. A faulty facilitator will fail step (2) if chunk is indeed different from the one registered by ; otherwise, the request is discarded because of faulty buyer behavior. Once the faulty party is detected, channel escrow balance is appropriately transferred to the honest party.

At the end of settlement and dispute resolution, offchain channel state is transferred on-chain, and application progresses, disputes continuing directly on blockchain with each party submitting messages directly to blockchain instead of each other.
We note that VADER automatically pays out royalty to  based on the successful exchanges submitted to blockchain during settlement phase. Therefore, VADER guarantees  fairness as long as  and  honestly report their offchain messages on chain and do not collude with each other. We next describe how VADER handles collusion between a malicious  and  and still guarantees  fairness.

: penalty amount

: channel id for ¡¿

1:function .SubmitClaim(, , )
4:  if  then
5:    Message signatures Invalid.
6:   return     
7:  if,¿ ¡,¿) AND
8:       then
9:     - collusion attack detected
10:     Penalize  and reward  
11:     -=
12:     +=
Algorithm 9 Penalizer Smart Contract

3.3. Preventing - Collusion

The offchain execution of VADER between  and  makes  vulnerable to a collusion attack 222The problem does not occur in case one of  or  are honest, as the adherence to protocol by any one party will force the other party to act honestly or loose out. where in  and  submit an altered set of offchain message exchanges during settlement to deny  of its fair share. We explain how such collusion can be undertaken next, followed by the description of the technique used to prevent such attacks.

Offchain Alternate Message Construction: Consider the case where  and  have completed a successful exchange of video owned by . Note that at this point,  has already received and  the desired file. Therefore, both parties are incentivized to collude to maximize profit by constructing a new set of message exchanges simulating 1)  requesting video owned by a sybil entity (’) controlled by  benefitting  , 2)  agreeing for price much lesser than benefiting . As part of alternate message construction,  creates a new Exchange Request Message , (m=¡, , , ¿,) with video id . Note that a rational  will reuse the ¡,¿ pair, since creating either a new or makes  vulnerable to  submitting it as legitimate evidence of exchange to blockchain, and withdrawing s money. We leverage the above nuanced message construction to detect and penalize collusion.

Penalizer Smart Contract: Specifically, following insight 3, we introduce another smart contract, Penalizer Alg 9, which will pay  a large penalty from ’s funds (deposited during channel funding in Init.2), if it can submit a pair of messages, in line 2 & 3, having same reqid and cid but different content id’s . The penalization scheme introduces an element of distrust between  and  and prevents collusion, forcing them to honestly report their offchain exchanges during settlement. In summary, our penalty scheme ensures that in a realistic setting, where most buyers are not controlled by , the  is disincentivized to collude with , for fear of paying a heavy penalty. Consequently our protocol guarantees fairness to all three parties viz. ,  and .
Limitations We note that the offchain nature of VADER entails a buyer (or its delegatee (McCorry et al., 2018)) to continuously remain online, and maintain significant local state, as well as lock up sufficient liquidity in channel till settlement. Consequently, VADER may not be appropriate for light weight clients that are ephemeral, lack local state or cannot afford to lock liquidity for long time, and depend solely on blockchain for tamper-proof logging and availability. We evaluate this model in Sec. 4.

Extension to multiple , ,  : In reality multiple parties can assume any of the roles in a single exchange (say multiple  of same content). Note that our protocols will work for even in such settings as long as all parties do no completely trust each other. This is due to the fact that any new entities participation will either be essential to the exchange and in which case, their concerns will be similar to that of an active party, whose rights are protected by VADER protocol. Alternatively, the party might not be essential for completing the exchange, in which case, their concerns will be similar to that of passive party which are also safeguarded by VADER protocol.

3.4. Security Analysis of VADER 

In this section we show that VADER is secure against Royalty Manipulation, Content Mismatch and Content Stealing attacks (Atk.1,2,3) defined in Sec. 2. We reiterate that as mentioned in Sec. 2 we do not address the orthogonal issue of content piracy.

Theorem 3.1 ().

Under the assumptions that, a) the digital signature scheme is unforgeable, b) the cryptographic hash function is collision-resistant and c) under honest majority, blockchain attributes (smart-contract execution and ledger) are tamper-resistant, we show that VADER protects fairness of honest and rational parties against Atk.1, 2 & 3.

Atk.1: VADER ensures that in presence of at least honest  or , all exchanges are recorded onto the blockchain during channel close either successfully or as a dispute. In case both  &  are malicious, VADER introduces distrust to prevents collusion between them through incentive techniques mentioned in Sec.3.3, forcing them to record correct state on the blockchain. Further, in VADER ’s royalty is calculated inside the blockchain trusted arbitrator (smart contract). So under the assumption (c) any royalty manipulation attack will not be feasible given honest majority of blockchain participants.

Atk.2 & 3: We analyse Atk.2, 3 in individual malicious parties and collusion cases as follows:

Malicious : A malicious  may target a content mismatch attack (Atk.2) by sending mismatching content () in Init.1, but for an honest  to accept mismatching content and hashes,  needs to find a collision in the hash function which is assumed impossible, making this attack infeasible. Content stealing (Atk.3) is useless for  as it owns the very content.
Malicious : For a malicious  to successfully launch a content mismatch (Atk.2), it has to send a content instead of as requested by . An honest  will not accept that unless  manages to find a collision in such that . Hence, under collision-resistant hash function assumption, Atk.2 does not occur. Content stealing (Atk.3) is meaningless for  and will not occur as it arguably owns the very content.
Malicious : A malicious  can try to mount content mismatch attack Atk.2 by raising a fraudulent complaint against  after receiving the correct content. However, since  and  exchange a co-signed message agreeing to (),  cannot generate s sign on a () due to the unforgeability of signatures assumption. Similarly, it cannot raise a complaint with Dispute Resolve without submitting a mismatching chunk which when encrypted under leads to the same hash, without finding a collision in the hash function, which is assumed impossible.
A malicious  cannot steal content(Atk.3) from  as as an honest  will not transfer the decryption key without payment in message and Dispute Resolve contract ensures that  provides to  before handing over the key .
- Collusion: A malicious  cannot help  with content mismatch attack (Atk.2) to cheat  by providing wrong content as an honest  requests for a particular content in the Xchg.1 step. Since  has no control over this step, this attack reduces to a malicious  case, which we already explained the protocol to be secure against. Also both  and  arguably own the content, hence obviating the need for content stealing attack (Atk.3).
- Collusion: Content mismatch (Atk.2) & stealing (Atk.3) attacks in this case would be  and  trying to exchange content through VADER but denying payment to . To this end,  may try to submit wrong (,) in Init.1 step, in order for  to raise a dispute. An honest  will not countersign a mismatching (), unless  finds a collision in which by assumption is impossible. Apart from Init.1,  does not participate in the remaining protocol, reducing these attacks to the malicious  case, which the protocol is secure against.
Note that the case of mutually known  and  carrying out entire exchange among themselves without involving , is orthogonal to the VADER setting wherein  and  do not know each other.
- Collusion: Rational  and  will not let a content mismatch attack (Atk.2) and content stealing attack (Atk.3) to occur respectively as they are hurt by the same. We ignore the case where a  (or any fake ’ ) sells the content to a  outside our ecosystem as that is a case of content piracy.
Under all the possible cases (corruption and collusion), VADER is secure against Atk.1, 2 and 3, thus completing the proof. We briefly highlight the reason for VADER to be secure even with multiple ,  or  in Sec. 3.3.

4. Implementation

We compare the performance of VADER against the following two baselines
VANILLA: We implemented VANILLA to emulate traditional HTTPS based video delivery as described in RFC (Pantos and May, 2017). VANILLA protocol does not use blockchain enabling us to benchmark performance overhead of VADER over state-of-art mechanisms.
Blockchain Mediated Exchange (BME): To understand the benefits of batching protocol messages, we implement BME protocol wherein  and  progress application state directly on blockchain instead of directly sending to each other as in VADER. In BME, akin to VADER, video is transferred offchain in encrypted format, while each exchange is directly settled onchain before starting the next. We note that in BME parties need not open & close a channel, and some messages can be batched while committing to blockchain, requiring only 3 commits (i.e. ¡,¿, ¡,,¿ & ¡¿) in happens before order. We incorporate the above optimizations in our implementation of BME.
Application Prototype: We implement  as a Django webapp (868 SLOC),  (256 SLOC) &  apps for VADER (699 SLOC), VANILLA (348 SLOC) and BME (617 SLOC), as Python applications.
Smart Contracts: We implement all VADER and BME functionalities as chaincodes (Smart Contracts) on top of Hyperledger Fabric (Hyperledger, 2019) v1.2 (Fabric) (Androulaki et al., 2018)

. We implement chaincode utilities for time estimation based on block height and conditional (time and condition locked) escrow accounts (no native crypto-currency in Fabric v1.2).

Maliciousness: We emulate a malicious  as one that sends non-matching chunk hashes to . Similarly, a malicious  is emulated by raising a dispute with the Dispute Resolve smart contract even after receiving the correct video from .

5. Evaluation

(a) CDN Topology (b) Random Topology
Figure 4. E2E time of VADER and BME normalized to VANILLA with # 500, # 10, 10% maliciousness exchanging random #files 10-250
Figure 5. File exchange timeline for an honest  exchanging 20 files, 20MB each under CDN topology

In our evaluation, we answer the following, 1) the performance overhead of VADER compared to baseline protocols, 2) the amortization benefits of VADER, 3) the effect of maliciousness on VADER performance, 4) the sensitivity of VADER to the underlying blockchain platform.

Experimental Setup: We run our experiments on 91 VMs (Ubuntu, 2.1GHz 16 CPU, 32GB, SSD) in Softlayer Cloud (40), across five geo-distributed data centers spanning four continents. Based on benchmarking, average latency was estimated at 0.4ms (and throughput 5Gbps) for intra-DC and varied 21.8-337ms (throughput 460-35.6Mbps) for inter-DC network. All experiments were conducted with a Fabric network consisting of 10 blockchain peers (one per  reflecting a network run by the s) running the default ordering service with out of the box configuration parameters (38).
Performance Metrics: We use the following metrics for quantifying performance overhead of the three schemes:1) end-to-end (e2e) time measures time elapsed from the instant  requests a file till it’s last chunk is ready for consumption (downloaded and decrypted) is our primary metric; 2) component contributions measured as the fraction of time spent in each sub component obtained by dividing e2e time into three components– a) Protocol Time is the total time spent in blockchain interactions and message exchanges between the parties; b) Transfer Time is the time taken for transferring encrypted chunks; c) Verify Time is the time spent by  in decrypting and verifying hash of the exchanged file. In the presence of maliciousness, this sub-component includes the time spent in interacting with the dispute resolution smart-contract;
Experimental Methodology: We benchmark the performance of VANILLA, VADER & BME under different realistic conditions by varying the underlying network topology, load on  and overall maliciousness in the system. Unless stated otherwise, we run our experiments for five iterations and report average results.

5.1. Macro Benchmarks

In this section we benchmark the performance overhead of all three schemes under realistic settings. We run 500 s in 5 DCs (100 s per DC, equally load-balanced among 5 VMs). The s are configured to exchange a 20MB file in chunks of 512KB 333Empirically determined to be optimal, results omitted for sake of brevity., random number of times (10 to 250, in increments of 5). We run 10 s  in 10 VMs equally distributed across the 5 DCs. We configure 10% of the s to be malicious (as described in Sec. 4).

5.1.1 CDN topology: We emulate a CDN like hierarchical topology implemented by real world facilitators (Torres et al., 2011; Adhikari et al., 2012a) where a  exchanges content from the nearest (same DC)  and measure e2e time for all the three schemes.

Performance Overhead: Non-Malicious: In Fig. 3(a), we plot the CDF of (median) e2e time for VADER and BME s, normalized to VANILLA. VADER adds only minimal overhead to VANILLA ranging from min. 12% to 16% at the median, making it a practically deployable system for providing fairness at scale. Notably 80% of the VADER s have an overhead of less than 23%. In contrast, BME has an overhead ranging from min. 690% to 764% at the median. This is due to the fact that VADER interacts with blockchain only twice (channel open and close) over multiple successful exchanges, while BME interacts with blockchain thrice for each exchange.

In summary, VADER is able to amortize blockchain interaction time over multiple exchanges leading to minimal performance overhead compared to VANILLA (16%) whereas, lack of amortization leads to significant degradation in BME (764%).

Performance overhead: Malicious: We also observe that maliciousness (10% of s) causes severe performance degradation shown by a lot worse performance (notch at 90%) for both VADER and BME. VADER adds an overhead of atleast 1160% while BME adds 9400% respectively for clients of malicious s. The performance degradation can be attributed to the overhead imposed by onchain execution of Dispute Resolve contract involving sign verification and waiting for settlement timeouts. as described in Alg. 8.

width= Blockchain Bitcoin Ethereum Litecoin Siacoin Monero Zcash Peercoin Dogecoin Consensus PoW PoW PoW PoW PoW PoW PoW & PoS Pow Block Gen. Time(s) 545.52 14.58 149.82 600.00 121.56 150.00 484.38 62.52 VADER (s) 5.88 0.57 1.92 6.42 1.64 1.92 5.26 1.05 BME (s) 1637.04 44.22 449.95 1800.48 365.17 450.48 1453.63 188.04

Table 1. VADER & BME average e2e expected latencies (per 20MB file) for public blockchain networks while batching 200, 20MB file exchanges in a session. Block generation time for Siacoin is from (20), for rest, 1/1/2019 from (14). PoW = Proof Of Work, PoS = Proof of Stake

5.1.2 Random topology: Next we evaluate the performance of VADER under a different network topology viz. random. We repeat the same experiment above, but allowing s to exchange content from a random  in any DC this time 444 Due to inter-dc network limitations and also to reduce the financial cost of the experiment, we restrict our file size to 5MB, keeping number of exchanges same (10 to 250). (To validate results, we have manually run experiments with 20MB files and found similar trends as reported). .

Fig. 3(b) shows that compared to VANILLA, VADER has a minimal overhead of 23% at the median compared to BME’s 391%. Interestingly, BME has lesser overhead in this scenario compared to the CDN scenario. This is due to the inter-dc network conditions that make network transfer times relatively worse for a large number of s across all three schemes. Consequently, overall network transfer time increases while the blockchain overhead remains the same making BME incur relatively lesser overhead compared to CDN topology.

Note that, VADER maintains its minimal overhead (23%) compared to VANILLA even under adverse network conditions making it deployable over a variety of network topologies.

5.1.3 Analysis of a single CDN experiment: To get a better understanding of when a file is available for viewing by a  (startup latency), we randomly select a single  from the CDN experiment. and depict the timeline of all file exchanges (20MB, 20 times), for all three schemes in Fig. 5. We note that, barring the one time channel open delay (1.61s), VADER adds only a minimal delay compared to VANILLA for each file, thereby not adversely affecting user experience. On the other hand, BME adds significant delay per file due to its three commit blockchain overhead added to each file. We also observe that, barring channel open and close overheads (3.2s), VADER adds only 7% delay over vanilla, making it a viable system.

5.1.4 Estimated performance on Public Blockchain Networks: We evaluate the sensitivity of VADER to underlying blockchain platform by estimating it’s performance on various public blockchains listed in Tab. 1. For this study, we calculate the median e2e time of a single file for VADER & BME and isolate it into two components viz. ‘blockchain protocol’ time and ‘miscellaneous’ time involving network transfer and crypto operations. We estimate blockchain protocol time for VADER by dividing twice the block generation time of the underlying blockchain (one each for channel open-close) by the number of file exchanges. For BME  we calculate protocol time as thrice the block generation time (corresponding to the three blockchain commits). Finally we add the miscellaneous overhead for both protocols to get the projected time taken by each.

We observe that even in the case of public blockchains, VADER’s amortization benefits drastically outperform BME. In the case of blockchain networks with high block generation time (such as Bitcoin) VADER is able to achieve 27.21Mbps, making it practical even on public blockchains, while BME throttles down to 0.01Mbps. On the other hand, in the case of a blockchain like Ethererum with lower block generation time, VADER can achieve nearly 280Mbps, which is comparable to VANILLA’s 384Mbps.

5.2. Micro benchmarks

In this section, we validate our design choices by benchmarking the performance of various system sub components. We allocate 10 VMs running a single  each, and run 200 s in 20VMs (20 buyers per vm). We configure s to exchange a 20MB file in chunks of 512KB, 50 times randomly from any . Default maliciousness is set to 0% (unless specified otherwise).

Figure 6. E2E time amortization w. increasing no. of file exchanges. (filesize 20MB)
Figure 7. E2E time vs increasing #s (20MB, 50 times)
Figure 8. Per component e2e time contribution vs #s (20MB, 50 times)

5.2.1 e2e time vs #files: Fig. 8 shows the effect of increasing #files (5 to 200) on average e2e time per file for a constant file size of 20MB. We observe that VADER overhead compared to VANILLA keeps decreasing with increasing no. of files, from 90%(5 files) to 13%(200 files). Clearly, VADER is able to amortize blockchain overhead over multiple files. On the other hand, note that the e2e time for BME increases rapidly with the no. of files, from 4.14s(5) to 18.7s(200) since BME bottlenecks by hitting the blockchain for each file.

5.2.2 e2e time vs #buyers: Next we study the effect of loading  by increasing no. of s from 10 to 50 per , keeping filesize (20MB) and #files (50) constant. In Fig. 8, we observe that VADER’s overhead increases from a mere 7% (0.71s) at 100 s to 31% (4.24s) at 500 s. This is explained by the extra load imposed on the s by the signing and verification, steps of VADER. In contrast, BME’s e2e time increases rapidly from 3.35s to 30.84s, due to the extra load on the blockchain layer (replicated execute and consensus) imposed by the increasing no. of commits, from increasing  count.

5.2.3 Component Analysis: Fig. 8 shows the component contribution (defined in Metrics, Sec. 5) towards e2e time of a file for VADER and BME protocols with increasing #s per . We observe that for VADER there is a 10x increase in network transfer time (from 0.34s to 3.35s), while protocol time increases 5x from 0.125s to 0.61s with increasing s. The large network transfer time increase in VADER is attributed to the fact that an increasing no. of s simultaneously fetch content (flash crowd) thereby putting more stress on s and the underlying network. ( We note that VANILLA network transfer time behaves in a similar fashion). On the other hand, the protocol time for BME increases rapidly (from 2.84s to 29.7s) with increasing #s while the network transfer time remains the same at around 0.34s. This is due to the fact that in the case of BME s, the blockchain commit wait times provide a more spaced out execution and  network time remains constant.

Figure 9. System wide avg e2e time per file vs % maliciousness (20MB, 50 times)
(a) 0% Malicious (b) 40% Malicious (c) 80% Malicious
Figure 10. CDF(s) of e2e time per  under increasing maliciousness. (20MB, 50 times)

5.2.4 Effect of Maliciousness: We study the effect of maliciousness by increasing maliciousness from 0% to 100% and plot average e2e time for VADER and BME in Fig. 10.  555 VANILLA does not have a dispute resolution mechanism, hence, we don’t run VANILLA in experiments benchmarking maliciousness. We observe that VADER starts with lower e2e time (1.53s) compared to BME (7.2s) for 0% maliciousness, while VADER e2e time increases with increasing maliciousness and coming closer to BME. This is due to the fact that after the first dispute, VADER closes channel and continues application progress directly on blockchain similar to BME.

In the worst case of 100% maliciousness, VADER begins to have higher completion time compared to BME due to the additional channel open-close overhead. In Fig. 10, it is interesting to note that in case of VADER, even in the presence of maliciousness, the non-malicious parties remain unaffected, and only s interacting with a malicious  incur higher e2e time. For example, e2e time for 60% of s is less than 1.65s with 40% maliciousness and jumps to 5.76s right after; and it is less than 1.59s for 20% of s in 80% maliciousness, after which it jumps to 6.34s.

6. Related Work

In this section, we review and contrast our work with existing work on building fair, auditable and decentralized systems.

Blockchain Platforms: Beginning with Bitcoin (Nakamoto, 2009), the recent past has seen the emergence of a number of blockchain platforms (Foundation, 2019; R3, 2019; Tendermint, 2019; Hyperledger, 2019; Quorum, 2019; cash, 2019), that provide a tamper proof immutable ledger of transactions as well as smart contract capabilities secured by an underlying consensus protocol. The various blockchain platforms vary in their choice of consensus protocol, transaction privacy models, as well as membership in the blockchain network. Permissioned/consortium model restricts blockchain access to only a few users/organizations, while permissionless model allows any node to join and participate in the network. Typical permissioned blockchain platforms also support access control capabilities at the smart contract layer to provide confidentiality guarantees to higher layer blockchain applications. VADER relies on granular access control, as well as tamper-proof smart contract execution and auditability of blockchain platforms, to guarantee multi-party fair exchange, even in the presence of passive participants.

Blockchain Scalability: The underlying consensus protocol overhead limits the scalability of blockchains. Recent solutions to addressing scalability broadly fall in two buckets.
Layer 1 Solutions: These solutions involve making onchain modifications to the underlying blockchain design such as changing the block size (Bitcoincash, 2019) or block generation time (Litecoin, 2019). The authors in  (Eyal et al., 2016) adopt a leader election based consensus algorithm for achieving faster consensus and block generation fairness in bitcoin.  (Danezis and Meiklejohn, 2016; Kokoris-Kogias et al., 2018; Luu et al., 2016; Al-Bassam et al., 2018) implement sharding to scale transaction throughput wherein the main blockchain is divided into multiple independent shards within which transactions can be validated in parallel, and finally merged into the main chain. Algorand (Gilad et al., 2017) uses a committee based consensus protocol, while RapidChain (Zamani et al., 2018) uses a mix of sharding and committee based consensus to improve the scaling further.We note that even if the above works are able to improve transaction throughput to a few thousand transactions per second, blockchain consensus will still impose a ceiling on transaction throughput

Layer 2 Solutions: An alternate design to scale throughput is to decouple transaction processing speed from the underlying blockchain protocol by reducing the number of interactions with the blockchain. Payment channels (Poon and Dryja, 2016; Raiden, 2019) and generalized state channels (Coleman et al., 2019; Perun, 2019; Technologies, 2019; Spankchain, 2019; Miller et al., 2017; Dziembowski et al., 2018b) enable parties to directly transact with each other off-chain and finally batch multiple transactions into a single blockchain transaction. This allows applications to scale independent of the blockchain protocol while offering security guarantees at par with native blockchain. While state channels help in scaling, they require 1) all parties to be known to each other apriori and 2) all parties (or their delegatee (McCorry et al., 2018)) to continuously remain online. On the other hand, VADER works even when parties are not known to each other apriori and one of the parties is passive and offline (content owner).

Fair Exchange: Fair exchange is a well studied problem, especially fairness for electronic commerce (Asokan, 1998). Two party fair exchange without a trusted third party (TTP) is known to be impossible (Rabin, 2005; Goldreich et al., 1987; Yao, 1986; Pagnia and Gärtner, 1999) without relaxing security requirements. Recent works have looked at designing blockchain based protocols for fair exchange (Andrychowicz et al., 2016; Kumaresan and Bentov, 2016; Kumaresan et al., 2016; Kiayias et al., 2016). Bentov (Bentov and Kumaresan, 2014) describe a bitcoin based claim-or-refund framework for fair exchange in which either parties receive the intended goods or are compensated monetarily. Building on this, the authors in FairSwap (Dziembowski et al., 2018a) describe a framework that enable a sender and receiver to exchange digital goods such as files in a fair manner through the use of a ‘judge’ smart contract. Choudhuri et al., 2017) design protocols that ensure fairness in secure multi-party computation using blockchain-like primitives. The above protocols guarantee fairness only between the active parties and do not cover passive participants, whereas VADER guarantees fairness even for passive parties.

Decentralized Marketplaces: Recent works on blockchain based decentralized marketplaces allow buyers and sellers to trade directly with each other without a centralized platform (Subramanian, 2018; Klems et al., 2017; Kabi and Franqueira, 2018; LBRY, 2019; Bazaar, 2019). In these systems, dispute resolution is handled offline in an ad-hoc manner, providing no guarantees on fairness. VADER on the other hand guarantees fair exchange and is better aligned with existing centralized marketplaces.
Video Streaming: Most commercial video streaming services (89; 82) follow RFC (Pantos and May, 2017) that describes the streaming of video over HTTP(S). There has been significant research in the design, measurement and characterization and optimization of scalable video streaming systems like (Dobrian et al., 2011; Adhikari et al., 2012a, b; Krishnappa et al., 2011; Ghasemi et al., 2016; Torres et al., 2011; Qin et al., 2018; Bentaleb et al., 2019) characterize the end to end performance of a commercial video streaming service and identify a number of bottlenecks across different layers of the stack. Similarly, (Torres et al., 2011) studies policies used for server selection in the Youtube CDN network. while the authors in (Balachandran et al., 2013) study the effects of CDN augmentation techniques such as P2P-CDN and telco-CDN federation on video workloads. Similarly, on the client side, a number of bitrate adaptation algorithms have been developed with the goals of minimizing buffering, start up latency, improving video smoothness etc. We note that above prior work’s focus on improving end user experience ard orthogonal to VADER’s focus on guaranteeing fairness.

Auditing Mechanisms: A number of works have looked at auditing running systems. PeerReview (Haeberlen et al., 2007) leverages tamper-evident logging to detect when a node deviates from the expected behaviour. AVMs (Haeberlen et al., 2010) on the other hand, use logging to record all incoming/outgoing messages from a VM and ensure correct execution of a remote system.  (Bhagwan et al., 2014) helps ad system operators debug revenue problems through multi-dimensional analysis of various metrics. However, the approach requires access to logs and other internal system metrics. Such works are not applicable in our setting as we do not trust facilitators to act honestly. Recent works have also focussed on auditing the working of web systems (Chen et al., 2015; Iordanou et al., 2017; Hannak et al., 2017; Jiang et al., 2018; Chen et al., 2016; Hannak et al., 2014) through black box measurements to detect violations in application defined fairness. However, these works are limited to detecting unfair practices and do not provide any mechanisms for guaranteeing fairness of the participants.

Complementary Technologies: We highlight complementary technologies that VADER can leverage to further enhance the security of the platform. Mangipudi (Mangipudi et al., 2018) use a combination of content watermarking and on-chain penalty mechanisms to prevent content piracy which can be easily embedded into VADER smart contracts. Emerging technologies such as Intel SGX (41) that provide computational integrity and verifiability through hardware mechanisms could be leveraged for protecting the confidentiality of videos stored on the video server.

7. Conclusion

We introduce the problem of Multi-party fair exchange for digital assets, which requires safeguarding the rights of active and passive participants. We propose a protocol to ensure Multi-party fair exchange for digital assets, by leveraging blockchain and intelligent incentive alignment. We build a prototype of the protocol on Hyperledger Fabric and extensively evaluate performance of our approach across a realistic test bed and show results that demonstrate the feasibility of our system.


  • V. K. Adhikari, Y. Guo, F. Hao, M. Varvello, V. Hilt, M. Steiner, and Z. Zhang (2012a) Unreeling netflix: understanding and improving multi-cdn movie delivery. In Proceedings of the IEEE INFOCOM 2012, Orlando, FL, USA, March 25-30, 2012, pp. 1620–1628. External Links: Link, Document Cited by: §1, §5.1, §6.
  • V. K. Adhikari, S. Jain, Y. Chen, and Z. Zhang (2012b) Vivisecting youtube: an active measurement study. In Proceedings of the IEEE INFOCOM 2012, Orlando, FL, USA, March 25-30, 2012, pp. 2521–2525. External Links: Link, Document Cited by: §6.
  • M. Al-Bassam, A. Sonnino, S. Bano, D. Hrycyszyn, and G. Danezis (2018) Chainspace: A sharded smart contracts platform. In 25th Annual Network and Distributed System Security Symposium, NDSS 2018, San Diego, California, USA, February 18-21, 2018, Cited by: §6.
  • E. Androulaki, A. Barger, V. Bortnikov, C. Cachin, K. Christidis, A. D. Caro, D. Enyeart, C. Ferris, G. Laventman, Y. Manevich, S. Muralidharan, C. Murthy, B. Nguyen, M. Sethi, G. Singh, K. Smith, A. Sorniotti, C. Stathakopoulou, M. Vukolic, S. W. Cocco, and J. Yellick (2018) Hyperledger fabric: a distributed operating system for permissioned blockchains. In Proceedings of the Thirteenth EuroSys Conference, EuroSys 2018, Porto, Portugal, April 23-26, 2018, pp. 30:1–30:15. External Links: Link, Document Cited by: §4.
  • M. Andrychowicz, S. Dziembowski, D. Malinowski, and L. Mazurek (2016) Secure multiparty computations on bitcoin. Commun. ACM 59 (4), pp. 76–84. External Links: Link, Document Cited by: §6.
  • [6] (2019) Apple introduces 14-day return on iTunes, scaring coders and musicians. Note: Online;[Online; accessed 13-Jun-2019] External Links: Link Cited by: §1, §1.
  • N. Asokan (1998) Fairness in Electronic Commerce. PhD Thesis, University of Waterloo, Canada. External Links: Link Cited by: §6.
  • A. Balachandran, V. Sekar, A. Akella, and S. Seshan (2013) Analyzing the potential benefits of cdn augmentation strategies for internet video workloads. In Proceedings of the 2013 Conference on Internet Measurement Conference, IMC ’13, New York, NY, USA, pp. 43–56. External Links: ISBN 978-1-4503-1953-9, Link, Document Cited by: §6.
  • O. Bazaar (2019) OpenBazaar: online marketplace | Peer-to-Peer Ecommerce. Note: [Online; accessed 13-Jun-2019] External Links: Link Cited by: §6.
  • A. Bentaleb, B. Taani, A. C. Begen, C. Timmerer, and R. Zimmermann (2019) A survey on bitrate adaptation schemes for streaming media over HTTP. IEEE Communications Surveys and Tutorials 21 (1), pp. 562–585. External Links: Link, Document Cited by: §6.
  • I. Bentov and R. Kumaresan (2014) How to use bitcoin to design fair protocols. In Advances in Cryptology - CRYPTO 2014 - 34th Annual Cryptology Conference, Santa Barbara, CA, USA, August 17-21, 2014, Proceedings, Part II, pp. 421–439. External Links: Link, Document Cited by: §6.
  • R. Bhagwan, R. Kumar, R. Ramjee, G. Varghese, S. Mohapatra, H. Manoharan, and P. Shah (2014) Adtributor: revenue debugging in advertising systems. In Proceedings of the 11th USENIX Symposium on Networked Systems Design and Implementation, NSDI 2014, Seattle, WA, USA, April 2-4, 2014, pp. 43–55. Cited by: §1, §6.
  • Bitcoincash (2019) BitCoin cash. Note: [Online; accessed 25-Feb-2019] External Links: Link Cited by: §6.
  • [14] (2019) Bitinfocharts Block Generation Time. Note: ”Online;”[Online; accessed 19-Jun-2019] External Links: Link Cited by: Table 1.
  • BitTube (2019) BitTube. Note: [Online; accessed 13-Jun-2019] External Links: Link Cited by: §1.
  • Z. cash (2019) Zero cash. Note: [Online; accessed 25-Feb-2019] External Links: Link Cited by: §6.
  • L. Chen, A. Mislove, and C. Wilson (2015) Peeking beneath the hood of uber. In Proceedings of the 2015 ACM Internet Measurement Conference, IMC 2015, Tokyo, Japan, October 28-30, 2015, pp. 495–508. External Links: Link, Document Cited by: §6.
  • L. Chen, A. Mislove, and C. Wilson (2016) An empirical analysis of algorithmic pricing on amazon marketplace. In Proceedings of the 25th International Conference on World Wide Web, WWW 2016, Montreal, Canada, April 11 - 15, 2016, pp. 1339–1349. External Links: Link, Document Cited by: §6.
  • A. R. Choudhuri, M. Green, A. Jain, G. Kaptchuk, and I. Miers (2017) Fairness in an unfair world: fair multiparty computation from public bulletin boards. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, CCS 2017, Dallas, TX, USA, October 30 - November 03, 2017, pp. 719–728. External Links: Link, Document Cited by: §6.
  • [20] (2019) Coingecko Siacoin Details. Note: [Online; accessed 17-June-2019] External Links: Link Cited by: Table 1.
  • J. Coleman, L. Horne, and L. Xuanji (2019) Counterfactual: generalized state channels. External Links: Link Cited by: §6.
  • G. Danezis and S. Meiklejohn (2016) Centrally banked cryptocurrencies. In 23rd Annual Network and Distributed System Security Symposium, NDSS 2016, San Diego, California, USA, February 21-24, 2016, Cited by: §6.
  • F. Dobrian, V. Sekar, A. Awan, I. Stoica, D. Joseph, A. Ganjam, J. Zhan, and H. Zhang (2011) Understanding the impact of video quality on user engagement. In Proceedings of the ACM SIGCOMM 2011 Conference, SIGCOMM ’11, New York, NY, USA, pp. 362–373. External Links: ISBN 978-1-4503-0797-0, Link, Document Cited by: §6.
  • DTube (2019) DTube. Note: [Online; accessed 13-Jun-2019] External Links: Link Cited by: §1.
  • S. Dziembowski, L. Eckey, and S. Faust (2018a) FairSwap: how to fairly exchange digital goods. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, CCS 2018, Toronto, ON, Canada, October 15-19, 2018, pp. 967–984. External Links: Link, Document Cited by: §6.
  • S. Dziembowski, S. Faust, and K. Hostáková (2018b) General state channel networks. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, CCS 2018, Toronto, ON, Canada, October 15-19, 2018, pp. 949–966. External Links: Link, Document Cited by: §3.1, §6.
  • [27] (2019) Etsy - digital prints. Note: [Online; accessed 13-Jun-2019] External Links: Link Cited by: §1.
  • I. Eyal, A. E. Gencer, E. G. Sirer, and R. van Renesse (2016) Bitcoin-ng: A scalable blockchain protocol. In 13th USENIX Symposium on Networked Systems Design and Implementation, NSDI 2016, Santa Clara, CA, USA, March 16-18, 2016, pp. 45–59. Cited by: §6.
  • E. Foundation (2019) Ethereum. Note: [Online; accessed 25-Feb-2019] External Links: Link Cited by: §6.
  • M. Ghasemi, P. Kanuparthy, A. Mansy, T. Benson, and J. Rexford (2016) Performance characterization of a commercial video streaming service. In Proceedings of the 2016 Internet Measurement Conference, IMC ’16, New York, NY, USA, pp. 499–511. External Links: ISBN 978-1-4503-4526-2, Link, Document Cited by: §6.
  • Y. Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich (2017) Algorand: scaling byzantine agreements for cryptocurrencies. In Proceedings of the 26th Symposium on Operating Systems Principles, Shanghai, China, October 28-31, 2017, pp. 51–68. External Links: Link, Document Cited by: §6.
  • O. Goldreich, S. Micali, and A. Wigderson (1987) How to play any mental game. In

    Proceedings of the Nineteenth Annual ACM Symposium on Theory of Computing

    STOC ’87, New York, NY, USA, pp. 218–229. External Links: ISBN 0-89791-221-7, Link, Document Cited by: §1, §6.
  • [33] (2019) Google play store. Note: [Online; accessed 13-Jun-2019] External Links: Link Cited by: §1.
  • A. Haeberlen, P. Aditya, R. Rodrigues, and P. Druschel (2010) Accountable virtual machines. In 9th USENIX Symposium on Operating Systems Design and Implementation, OSDI 2010, October 4-6, 2010, Vancouver, BC, Canada, Proceedings, pp. 119–134. Cited by: §1, §6.
  • A. Haeberlen, P. Kouznetsov, and P. Druschel (2007) PeerReview: practical accountability for distributed systems. In Proceedings of the 21st ACM Symposium on Operating Systems Principles 2007, SOSP 2007, Stevenson, Washington, USA, October 14-17, 2007, pp. 175–188. External Links: Link, Document Cited by: §1, §6.
  • A. Hannak, G. Soeller, D. Lazer, A. Mislove, and C. Wilson (2014) Measuring price discrimination and steering on e-commerce web sites. In Proceedings of the 2014 Internet Measurement Conference, IMC 2014, Vancouver, BC, Canada, November 5-7, 2014, pp. 305–318. External Links: Link, Document Cited by: §6.
  • A. Hannak, C. Wagner, D. García, A. Mislove, M. Strohmaier, and C. Wilson (2017) Bias in online freelance marketplaces: evidence from taskrabbit and fiverr. In Proceedings of the 2017 ACM Conference on Computer Supported Cooperative Work and Social Computing, CSCW 2017, Portland, OR, USA, February 25 - March 1, 2017, pp. 1914–1933. External Links: Link Cited by: §6.
  • [38] (2018) Hyperledger Fabric Github. Note: [Online; accessed 19-Aug-2018] External Links: Link Cited by: §5.
  • Hyperledger (2019) Hyperledger Fabric. Note: [Online; accessed 25-Feb-2019] External Links: Link Cited by: §4, §6.
  • [40] (2019) IBM Softlayer Cloud Docs. Note: ”Online; IBM Cloud Docs”[Online; accessed 17-June-2019] External Links: Link Cited by: §5.
  • [41] (2019) Intel Software Guard Extensions (SGX). Note: [Online; accessed 13-Jun-2019] External Links: Link Cited by: §6.
  • C. Iordanou, C. Soriente, M. Sirivianos, and N. Laoutaris (2017) Who is fiddling with prices?: building and deploying a watchdog service for e-commerce. In Proceedings of the Conference of the ACM Special Interest Group on Data Communication, SIGCOMM 2017, Los Angeles, CA, USA, August 21-25, 2017, pp. 376–389. External Links: Link, Document Cited by: §6.
  • S. Jiang, L. Chen, A. Mislove, and C. Wilson (2018) On ridesharing competition and accessibility: evidence from uber, lyft, and taxi. In Proceedings of the 2018 World Wide Web Conference on World Wide Web, WWW 2018, Lyon, France, April 23-27, 2018, pp. 863–872. External Links: Link, Document Cited by: §6.
  • O. R. Kabi and V. N. L. Franqueira (2018) Blockchain-based distributed marketplace. In Business Information Systems Workshops - BIS 2018 International Workshops, Berlin, Germany, July 18-20, 2018, Revised Papers, pp. 197–210. External Links: Link, Document Cited by: §6.
  • A. Kiayias, H. Zhou, and V. Zikas (2016) Fair and robust multi-party computation using a global transaction ledger. In Proceedings, Part II, of the 35th Annual International Conference on Advances in Cryptology — EUROCRYPT 2016 - Volume 9666, New York, NY, USA, pp. 705–734. External Links: ISBN 978-3-662-49895-8, Link, Document Cited by: §6.
  • M. Klems, J. Eberhardt, S. Tai, S. Härtlein, S. Buchholz, and A. Tidjani (2017) Trustless intermediation in blockchain-based decentralized service marketplaces. In Service-Oriented Computing - 15th International Conference, ICSOC 2017, Malaga, Spain, November 13-16, 2017, Proceedings, pp. 731–739. External Links: Link, Document Cited by: §6.
  • E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, and B. Ford (2018) OmniLedger: A secure, scale-out, decentralized ledger via sharding. In 2018 IEEE Symposium on Security and Privacy, SP 2018, Proceedings, 21-23 May 2018, San Francisco, California, USA, pp. 583–598. External Links: Link, Document Cited by: §6.
  • D. K. Krishnappa, S. Khemmarat, L. Gao, and M. Zink (2011) On the feasibility of prefetching and caching for online TV services: A measurement study on hulu. In Passive and Active Measurement - 12th International Conference, PAM 2011, Atlanta, GA, USA, March 20-22, 2011. Proceedings, pp. 72–80. External Links: Link, Document Cited by: §6.
  • R. Kumaresan and I. Bentov (2016) Amortizing secure computation with penalties. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS ’16, New York, NY, USA, pp. 418–429. External Links: ISBN 978-1-4503-4139-4, Link, Document Cited by: §6.
  • R. Kumaresan, V. Vaikuntanathan, and P. N. Vasudevan (2016) Improvements to secure computation with penalties. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS ’16, New York, NY, USA, pp. 406–417. External Links: ISBN 978-1-4503-4139-4, Link, Document Cited by: §6.
  • LBRY (2019) LBRY - Content Freedom. Note: [Online; accessed 13-Jun-2019] External Links: Link Cited by: §1, §6.
  • Litecoin (2019) Litecoin. Note: [Online; accessed 25-Feb-2019] External Links: Link Cited by: §6.
  • Livepeer (2019) Livepeer - Peer to peer video services. Incentivized.. Note: [Online; accessed 13-Jun-2019] External Links: Link Cited by: §1.
  • L. Luu, V. Narayanan, C. Zheng, K. Baweja, S. Gilbert, and P. Saxena (2016) A secure sharding protocol for open blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, Vienna, Austria, October 24-28, 2016, pp. 17–30. External Links: Link, Document Cited by: §6.
  • E. V. Mangipudi, K. Rao, J. Clark, and A. Kate (2018) Automated penalization of data breaches using crypto-augmented smart contracts. IACR Cryptology ePrint Archive 2018, pp. 1050. External Links: Link Cited by: §1, §2, §6.
  • L. Marshall (2015) ‘Let’s keep music special. f—spotify’: on-demand streaming and the controversy over artist royalties. Creative Industries Journal 8 (2), pp. 177–189. External Links: Document, Link Cited by: §1, §1.
  • P. McCorry, S. Bakshi, I. Bentov, A. Miller, and S. Meiklejohn (2018) Pisa: arbitration outsourcing for state channels. IACR Cryptology ePrint Archive 2018, pp. 582. External Links: Link Cited by: §3.3, §6.
  • A. Miller, I. Bentov, R. Kumaresan, and P. McCorry (2017) Sprites: payment channels that go faster than lightning. CoRR abs/1702.05812. External Links: Link, 1702.05812 Cited by: §6.
  • S. Nakamoto (2009) Bitcoin: A peer-to-peer electronic cash system,” Note: [Online; accessed 13-Jun-2019] Cited by: §6.
  • [60] (2019) New Scam Holds YouTube Channels for Ransom. Note: ”Online;”[Online; accessed 13-Jun-2019] External Links: Link Cited by: §1.
  • [61] (2019) Not getting paid at all?. Note:[Online; accessed 13-Jun-2019] Cited by: §1, §1.
  • H. Pagnia and F. C. Gärtner (1999) On the impossibility of fair exchange without a trusted third party. Technical report . Cited by: §1, §6.
  • R. Pantos and W. May (2017) HTTP live streaming. RFC 8216, pp. 1–60. External Links: Link, Document Cited by: §4, §6.
  • Perun (2019) Perun Network. Note: [Online; accessed 24-Apr-2019] External Links: Link Cited by: §6.
  • J. Poon and T. Dryja (2016) The bitcoin lightning network: Scalable off-chain instant payments. External Links: Link Cited by: §3.1, §6.
  • Y. Qin, S. Hao, K. R. Pattipati, F. Qian, S. Sen, B. Wang, and C. Yue (2018) ABR streaming of vbr-encoded videos: characterization, challenges, and solutions. In Proceedings of the 14th International Conference on emerging Networking EXperiments and Technologies, CoNEXT 2018, Heraklion, Greece, December 04-07, 2018, pp. 366–378. External Links: Link, Document Cited by: §6.
  • J. Quorum (2019) Quorum - a permissioned implementation of ethereum supporting data privacy. Note: [Online; accessed 25-Feb-2019] External Links: Link Cited by: §6.
  • R3 (2019) Corda. Note: [Online; accessed 25-Feb-2019] External Links: Link Cited by: §6.
  • M. O. Rabin (2005) How to exchange secrets with oblivious transfer. IACR Cryptology ePrint Archive 2005, pp. 187. External Links: Link Cited by: §1, §6.
  • Raiden (2019) Raiden Network. Note: [Online; accessed 24-Apr-2019] External Links: Link Cited by: §6.
  • Sandvine (2018) ”The global internet phenomena report october 2018”. Note: Online;[Online; accessed 21-Jun-2019] External Links: Link Cited by: §1.
  • H. Sivonen (2013) ”Encrypted media extension: eme-drm”. Note: [Online; accessed 2013-10-16] External Links: Link Cited by: §1, §2.
  • Spankchain (2019) Spankchain A blockchain based payment processor and live video streaming platform.. Note: [Online; accessed 24-Apr-2019] External Links: Link Cited by: §6.
  • [74] (2019) Spotify. Note: [Online; accessed 13-Jun-2019] External Links: Link Cited by: §1.
  • [75] (2019) Steam. Note: [Online; accessed 13-Jun-2019] External Links: Link Cited by: §1.
  • H. Subramanian (2018) Decentralized blockchain-based electronic marketplaces. Commun. ACM 61 (1), pp. 78–84. External Links: Link, Document Cited by: §6.
  • F. Technologies (2019) Funfair Blockchain solutions for gaming. Note: [Online; accessed 24-Apr-2019] External Links: Link Cited by: §6.
  • Tendermint (2019) Tendermint. Note: [Online; accessed 25-Feb-2019] External Links: Link Cited by: §6.
  • [79] (2019) The global video streaming market size. Note: ”Online;”[Online; accessed 13-Jun-2019] External Links: Link Cited by: §1.
  • A. C. to the YouTube Partner Program (YPP) to Better Protect Creators (2018) How to earn money on YouTub