Enabling mechanisms

Means of verification of remote storage and P2P peers fair payment must be supported by the payment-based incentive model, given that it relies on periodic fair exchange of credits between the contributing peers and consuming peers in the storage system, and periodic verification of remotely stored data at some holder peers by some verifier peers. We discuss in this section solutions that aim at providing these means.

Related work

There are several micropayment schemes that have been proposed in the past like PayWord, MicroMint [Rivest and Shamir 1996], and Millicent [Glassman et al. 1995] that particularly

present a centralized functionality marked by a central broker, the bank, that tracks each peer balance and payment transactions. In most of these schemes, the load of the bank grows linearly with the number of transactions; though hash chains in PayWord or the use of electronic lottery tickets [Rivest 1997] greatly reduce such cost. As example, the P2P micropayment system MojoNation⁵² has also a linear broker’s load and this system has gone out of work because the central bank constitutes also a single point of failure.

The scale of the P2P system makes it necessary to resort to a type of protocols termed optimistic protocols where the bank does not necessarily take part in the payment, but may be contacted to arbitrate litigations between peers. With such type of protocols, the bank’s work is reduced. PPay [Yang and Molina 2003] is a lightweight micropayment scheme for P2P systems where the issuer of any coin is a peer from the system that is responsible for keeping trace of the coin. However, the bank comes into play when the issuer of a coin is off-line. In a very dynamic system, the probability of finding the original issuer of the coin on-line is very low. In this situation, PPay converges to a system with a centralized bank. Additionally, tamper resistant hardware (TRH) can be used to enforce payment protocols in a decentralized and optimistic fashion as illustrated by the TermiNodes [Buttyán and Hubaux 2001] and CASHnet [Weyland et al. 2005] projects.

To the best of our knowledge, the only fully-decentralized micropayment scheme that exists so far is KARMA [Vishnumurthy et al. 2003]. KARMA splits the bank functionality in different bank sets composed of peers selected and appointed randomly from the P2P system for each peer when it first joins the system. The KARMA payment scheme does not require any trusted infrastructure and is scalable. The scheme is described in more detail in the following section.

DHT-based payment framework

The KARMA framework [Vishnumurthy et al. 2003] proposes a payment protocol in which peers’ balance and payment transactions are handled by a set of peers from the system network.

KARMA proposes to substitute the bank by a set of peers randomly assigned within a distributed Hash Table (DHT) for each peer, called bank-set. The karma value, which constitutes the name of the currency, is maintained for each peer by its bank-set whose members are collectively responsible for continuously increasing and decreasing the karma value as peers contribute and consume resources from the P2P system (see Figure 35).

The bank-set is randomly assigned to each peer: the b closest peers to HASHB(Id(Peer)) belong to the bank-set of that very peer (HASHB is a pseudo-random function publicly known).

The bank-sets independently track the credits belonging to their assigned peers, and periodically agree on a given balance of credits with a majority rule. Even if there are inconsistencies in peer balances, transactions among peers correspond to tiny micropayments and thus do not produce considerable gains or losses to peers. Peers joining the system for the first time must solve a cryptographic puzzle in order to mitigate Sybil attacks against the storage system. The payment protocol in KARMA is similar to an online bank payment but with additional features that guarantee the consistence and synchronization of peer balances.

52 MojoNation archived website.http://web.archive.org/web/20020122164402/%20http://mojonation.com/

Figure 35 KARMA framework: 1) payee sends a transfer request to its banker set; 2, 3) after confirming the transfer from the payer’s banker set, 4) payee’s banker set will send back receipt to the payee.

The payment scheme proposed in this section relies on this framework to guarantee the fair exchange of payment against some storage space. The KARMA framework has also been applied to the file sharing problem described in [Vishnumurthy et al. 2003]. That application cannot be assimilated to a P2P storage application since in the former case, payments are immediately charged after the exchange of the file, whereas in the latter case, payments for storage or verification are by installment i.e., they are billed at a due date that corresponds to the confirmation (by verifications) of the good behavior of the holder or the verifier. Therefore, we will supplement the KARMA framework by an escrowing mechanism (described in detail later on) that guarantees the effective payment of credits promised by the owner towards a cooperative holder or a verifier.

Remote data verification

Our proposed scheme uses a verification protocol based on pre-computed challenges (see Figure 36). These challenges are generated by the owner and stored at the verifier. Each verifier metadata consist of the random numbers and their corresponding pre-computed challenges (the reader may refer to the first solution in [Deswarte et al. 2004] for details).

The number of verification operations is limited by the number of pre-computed challenges stored at the verifier. This limitation does not restrain our mechanism because payments of holders or verifiers should be in essence computable (in number and price); and also the number of verification operations should be proportional to such payments. Besides, we opted for this type of verification protocol because it does not require special cryptographic functions (just a hashing function), in addition to the fact that the computational and storage overhead from the verifier side and the holder side are optimized.

Figure 36 Used verification protocol