Accounting in Peer-to-Peer Systems

Introduction

Peer-to-Peer applications have experienced overwhelming success. However, till today there is still no commercial Peer-to-Peer “Killer-App” (apart from Skype, which is free to use if the users do not call into a telephone network). Requirements necessary in order to build commercial Peer-to-Peer applications had to be determined. The requirements showed that a trust worthy accounting system would be of the highest importance. Trustworthy accounting information is required for any charging and billing process. Furthermore, it is important that the users are able to trust the system and that it is fair and secure. This trust can be built by delivering objective accounting information to the user. Accordingly, in EMEPPS we have developed an accounting mechanism which meets defined requirements such as:

  • The mechanism must be fully decentralized.
  • The generated accounting data must be trustworthy, i.e. information integrity must by ensured.
  • The mechanism should deliver complete accounting information, which includes information about a peer's actions across the system.
  • Legally binding accounting information should be possible.
  • The mechanism must be scaleable.

The resulting accounting mechanism is a token-based solution.

Token-based Accounting Mechanism for Peer-to-Peer Systems

Tokens are objects that represent transactions in the P2P system. They must be issued to a peer before usage. The main purpose of tokens is the storage of transaction relevant data. Therefore, tokens may be considered as issued receipts.

Each peer holds a local account containing a specific amount of tokens issued to it. In order to receive a service, a peer must spend a specific amount of tokens by sending them to the service provider. Accordingly, when a peer provides a service it collects tokens from the customer peers.


 

Thus, without enough tokens a peer is not able to receive a service. Foreign tokens cannot be reused. Therefore, a peer must exchange “foreign” tokens received against new own ones. New tokens must be signed with a system private key, in order to make them valid and to prevent forgery. To issue new tokens, the token-based accounting mechanism uses a distributed process employing threshold cryptography. The private key is split into several parts. Peers with high trust values (requiring a reputation system), so-called trusted peers each hold one part of the private key. A small number of trusted peers have to sign new tokens with their key part, before the owner peer can combine these partial tokens for a new signed token.


To avoid double spending by a peer, a set of so-called account holders are assigned. These account holders are third party peers who hold a list of tokens issued to the account owner. By using this list before any transaction is executed, a service provider (the token receiver) can check if the tokens which a customer intends to spend are valid.


Before a transaction, the account holder is also further allowed to check if a token was spent before. Furthermore, it allows a trustworthy transaction to be implemented, in which each participant in the transaction has no incentive to defraud another.

After a service request is received, the provider P notifies the consumer C about the conditions and terms of the transaction, including the required amount of tokens. C answers with the token IDs of the tokens it intends to spend for the transaction. Now P contacts the account holders responsible for C AH(C) and checks if the tokens are valid. AH(C) mark in the token list these tokens as "planned to spend''. Using the same tokens in another transaction thus becomes impossible. If all tokens are valid, P informs C that the transaction phase may begin. C starts the transaction by sending an unsigned token to P. C loses the token. However, since it is not signed by C, P cannot exchange it against own tokens. P has no motive not to provide the service. Therefore, P now provides the agreed service. Thus since C has already lost the token, it has no intention of keeping the token for itself. C will sign the token and send it to P. Should C fail to send the signed token, P can present the unsigned token to C. The possession of a token proves that the transaction has started and that the token will be removed from the list and is finally lost for C.

Evaluation

Security of the system depends on the unanimous vote of quorum peers, i.e. to avoid tokens from being forged, we require that at least one honest peer is present in a quorum. Thus, the quorum peers must be selected in a random manner. In order to ensure this, the token exchange process is much more complicated than as depicted in the above figures. It includes an anonymizing step which ensures that the exchanging peer is not able to determine which trusted peer it is who is creating the new tokens and determining the quorum.

The required quorum size for a secure accounting system can be determined using the hypergeometric probability function. Assuming 50% of the trusted peers are honest we require a quorum size of 17 for the probability of 99.999% that there is at least one honest peer in the quorum. For a probability of 99.99999% the required quorum size grows to 24.

In order to analyze the overhead traffic created, we have compared the token-based accounting scheme with KARMA [2], a system which relies on remote peers who host the accounting data.


Comparison of the two schemes shows that the token-based accounting scheme creates significantly less traffic than KARMA. The reason behind this is that the token-based accounting scheme stores the accounting data (tokens) locally at the peers. Furthermore, for KARMA's bank set a size of 64 is suggested. In the token-based accounting scheme, the account holder set has a similar functionality. Here, the set size can be much smaller as the lose of this data would still allow the peer to carry out transactions. Furthermore, the account holder set implements an additional security mechanism. In order for the mechanism to be effective, it is sufficient that the peers assume that mechanism is working. Therefore, a much smaller account holder set may be applied, e.g. a size of 4 - 8 is sufficient.


The proposed system was published in [1] and received at KiVS 2005 the Best Paper Award. Also, the system has been applied for patenting under EU patent application No. 04 101 386.3.


[1] N. Liebau, V. Darlagiannis, A. Mauthe, and R. Steinmetz: Token-based Accounting for P2P-Systems; In Proceeding of Kommunikation in Verteilten Systemen KiVS 2005, pages 16-28, February 2005. (Received Best Paper Award).

[2] V. Vishnumurthy, S. Chandrakumar and E. G. Sirer: KARMA: A Secure Economic Framework for Peer-to-Peer Resource Sharing; Proceedings of the Workshop on the Economics of Peer-to-Peer Systems, 2003.