Accounting Objects

As described in Chapter 1, the primary goals of the proposed system are

1. to globally collect accounting information about resources and services provided and consumed by the peers in a p2p system.

2. to enforce norms about cooperation based on the collected information by constraining access to resources and services accounted for.

Required System Characteristics

These goals imply five characteristics the system requires to achieve:

• The system collects receipts of the transactions the system accounts for. These collected receipts will be referred to as accounting information.

• The accounting information is collected system-wide and per peer.

• When accessing the collected accounting information it is available in a complete, correct and prompt manner.

• In order to enforce norms of cooperation, there is a mechanism to deny access to services or resources for entities that do not comply with the norms.

• There is a clear, apparent, and unforgeable flag showing, if a peer is permitted to access services or resources.

Another general requirement is the trustworthiness of the accounting scheme. Due to the assumptions the scheme is built on, Sybil attacks (Dou02) as well as Whitewashing attacks are prevented. When designing the system potential cheating and collusion of peers has to be taken into special consideration.

Hereafter, peers not behaving according to the rules will be called “misbehaving peers”.

The complexities of the researched solution are completely different than in client-server oriented systems with a central trusted entity that administers accounting information. How the remaining char- acteristics can be realised in a distributed autonomous system will now be addressed.

Accounting Receipts

The first characteristic is obvious to achieve. A receipt must be created that contains the required accounting information about each transaction, be it a service or resource usage. The information au- thentication, integrity and non-repudiation must be ensured.

As an example, peer A downloads a media file from peer B. Here, A has to certify that it received a service from B in form of a receipt. Both transaction partners should state their agreement to the information contained in the receipt.

Basic Cooperation Rule

In order to coordinate resource and service usage, a balance between offered and demanded resources and services must be achieved. Demand for free-of-charge resources and services will always exist. In contrast, free-of-charge resources and services will only be offered by altruistic system entities, which must be assumed to be the distinct minority of peers in the system. Thus, a balance between offer and demand can only be achieved if resource and services usage requires to reciprocation.

In conclusion, a basic behaviour rule to be supported by the accounting system is that in order to use accounted resources or services, a peer also has to provide resources and services.

Enforcing Cooperation in Distributed Autonomous Systems

In distributed autonomous systems, it is hard to enforce cooperation, as no central entity exists that can deny access to the distributed resources or services. The problem can best be observed from the opposite direction. Each peer that wishes to participate in the distributed autonomous system must have the permission to do so. This permission can be bound to an object. Only if the peer is in possession of such an object, can it use resources and services.

There are two alternatives for such a permission object. In the first alternative, a permanent permission object could be issued to peers. When a peer is not permitted to consume services or resources anymore, the permission will be revoked, and the peer will be black-listed. This implies that for each transaction in the system, the service provider first must check the black-list. The second alternative issues a permission object to peers that can be used only once. Here, the behaviour enforcement is more fine grained. However, there must be controls ensuing that permission objects are not used more than once. This is called Double Spending.

An accounting system requires a receipt per transaction. This could be combined with a corresponding permission object per transaction. Therefore, the second alternative presented above, using a permission object with onetimeuse is the preferred solution.

As a permission object should be used only once, there must be a way to use it up. The solution is to design it as “fading”. That is, if the permission object is used, it “fades” and cannot be used again. But it can be renewed if the peer acted according to the rules.

The result of these considerations is to introduce objects in the distributed autonomous system that represent the things that should be accounted for, i.e. they represent the right to use the services and resources that are accounted for. These objects should be scarce in order to enable behaviour rule enforcement. From this it follows that in order to ensure the scarceness of the permission object they must be issued by some decentralised process. This process must be governed by rules about when permission objects should be issued. The compliance with the rules must be checked by the system’s peers. They have a motivation to do so because, as previously described, it is assumed that the system

entities have an interest in a system that accounts for resource and service usage. Otherwise, they would move to a different system.

Tokens as Accounting Objects and Permission Objects

The accounting system for autonomous distributed systems with the described goals requires two types of objects: objects that hold accounting information and permission objects. One type of objects is required before a transaction takes place (permission), the other type is required after the transaction took place (accounting). Therefore, both objects can be combined into one object that is used throughout all phases of the transaction. An advantage is that identity information must be proved only once in a transaction, because both type of objects require that information.

Objects that hold accounting information typically are receipts. As the permission objects must be issued, the accounting system requires pre-transaction issued receipts. This special type of object is called a Token throughout this dissertation.

Renewing Permission Objects

Tokens are “fading” permission objects. A peer will loose tokens when consuming resources or services. This will be called spending tokens. However, when behaving according to the rules a peer should get the tokens “re-newed”. “Re-newing” tokens means, new tokens should be issued to the peer. According to the basic behaviour rule tokens should be issued when providing resources or services. As proof for provisioning also tokens are used, as they are the receipts. Thus, system must support a mechanism where peers can swap “receipt-tokens” against new “permission-tokens”.

Basic Accounting Scheme Concept

In conclusion, every participant in a system applying the accounting mechanism has a limited number of tokens they can use in transactions. The service provider keeps the accounting records about transac- tions. A participant who runs out of issued receipts is not allowed to consume any further services. This mechanism enables the enforcement rules. Participants will collect tokens when providing accounted resources or services. These “token-receipts” they can swap for new tokens. This mechanism enables to coordinate resource and service usage in the distributed autonomous system.

As example, Peer A requests a media file from Peer B. When B uploads the media file to A, A will take one of its tokens and fill in accounting information required for that service. Then it will send the token over to B. B receives a used token and will swap it for a new token. Thus, A spent a token and B earned a token. B keeps the accounting record about the transaction stored in the used token.

As a consequence, potential forgery and double spending of tokens must be addressed in the design of the accounting scheme2_.

Figure 3.1 depicts the concept. Note, that the location where new tokens and used tokens are stored has not yet been decided. Furthermore, note that the decentralised reputation system is separate from the token-based accounting scheme (see Section 3.1) and its design is beyond the scope of this disserta- tion.