The aggregation function adds another degree of freedom to the token-based accounting scheme, be- cause it can take any form. In this way, different rules can be realised, e.g., to implement specific economic mechanisms or norms of behaviour.
Simple forms of the aggregation function manipulate only the swapping ratio between foreign tokens and new own tokens. This is meaningful, for example, if the token-based accounting scheme is used as an incentive system. Due to the existence of altruistic peers, some peers might collect a lot of own tokens but will not spent them. If the aggregation function implements a swapping ratio of 1:1, the number of tokens available to peer will drop over time. This would result in a a deflation-like effect, which can reduce the overall system performance. Therefore, here different swapping ratios are appropriate. Obviously, the aggregation function can also be used to control the number of tokens that are available in the system.
Other aggregation functions can take other information into account. For example, the accounting information stored in the tokens could be evaluated. Such an aggregation function could, e.g., give priorities to specific services. For example, in file sharing systems files with high demand or files with very few copies could be prioritised. Tokens can be used as a means to incite users to provide accounted resources and services. Therefore, the aggregation function can also be used to coordinate the resources and services according to the demand. If demand is distinctively higher than supply, an appropriate aggregation function can be used to even out the difference.
Information about peers can also be taken into account. Peers that have a very high reputation value can be rewarded. The opposite is also possible in order to punish malicious behaviour. Another alterna- tive is to give a bonus to the 10% of peers that provided the most service.
Peer
Trusted Peer Trusted Peer Trusted Peer Trusted Peer Trusted Peer 6 New (unsigned) Tokens Partially signed Tokens 5 5 5 5Token Aggregation
Prevent Double Spending
IDs 8 Collected (foreign) Tokens Partially signed Tokens New Tokens 7 9 Avoid double spending Account Holder Account Holder 2 4 7 10 New Tokens Service Request Price ( ) Service Ready 1 IDs Combining tokens IDs
C
u
s
to
m
e
r
P
ro
v
id
e
r
P
ro
v
id
e
r
Account Holder Account Holder Account Holder 3 Signing with key shareAccount Holder
This short discussion shows that there is an unlimited number of alternatives for defining the aggre- gation function and for implementing different rules, preferences, and economic mechanisms.
3.9 Summary
This chapter presents the system architecture of the token-based accounting scheme. First, the design decisions leading to the system architecture are presented, and then each of the resulting building blocks is described.
The goal of this dissertation is to build a p2p accounting system with intrinsic cooperation control. Based on the requirements and design goals stated in Chapter 1, the system framework is deduced step-by-step. For each design step, the design alternatives are evaluated.
Accounting requires receipts for transactions that were performed by the system’s peers. Decentralised cooperation control requires permission objects; peers are permitted to receive accounted resources and services only if they are in possession of permission objects. The derived solution combines the transaction receipts and permission objects into one object called a token. Tokens are issued to peers using a fully decentralised process. Peers spend tokens for consuming accounted resources or services. Furthermore, tokens are allowed to be used only once. When a peer runs out of tokens, it cannot consume any further resources or services. A peer can request additional tokens by swapping foreign tokens it received for providing resources or services for new tokens. The system-wide aggregation function computes the number of new tokens a peer will receive. This combination implements effective decentralised cooperation control based on accounting data.
The aggregation function adds another degree of freedom to the token-based accounting scheme and can take any form. In order to implement different rules and policies in the p2p system, it can, for example, consider accounting information, reputation values, etc.
The system architecture that results from this framework consists of four building blocks: token struc- ture, transaction protocols, token aggregation, and detection of double spending. The token structure ensures information integrity so that tokens cannot be forged or stolen. Therefore, in order to issue it, it contains a signature with a system-wide private key. The transaction protocols define the process how peers “spent” tokens in order to receive accounted resources or services. A trustworthy transac- tion process was developed that removes the benefits for peers that defraud their transaction partner. Token aggregation is the process that enables peers to swap foreign tokens they received for providing resources or services for new own token. In token aggregation using the aggregation function, the num- ber of new tokens is computed that the swapping peer will receive. Then, each token is signed with the scheme’s private key by a quorum of trusted peers using threshold cryptography. Peers might be tempted to spend tokens several times in different transactions. Therefore, detection of double spending maintains for each peer an aggregation account at remote peers. This aggregation account receives in- formation during token aggregation about which tokens are issued to the peer. Also during transactions, the aggregation accounts are updated concerning which tokens have been spent. Thus, double spending can efficiently be detected.
In conclusion, the token-based accounting scheme consists of four building blocks that are closely interlinked. This combination allows trustworthy accounting with intrinsic cooperation control. In the following chapter further details about the protocols are presented. These details are important to demonstrate the viability of the token-based accounting scheme, as they further enhance the scheme’s trustworthiness.
4 Relevant Details About Protocols
Chapter 3 described the token-based accounting scheme’s architecture. Understanding the basic processes, there are still several open issues and new challenges arise. This chapter presents the solutions and detailed protocols to these issues and challenges. The focus here is on detecting and eliminating fraud.
Section 4.1 discusses how peers can be clearly identified permanently and how their peer id can be tied to a real world identity.
The usage of account holder sets was introduced in the previous chapter: The account holder set requires a number of mechanisms in order to demonstrate the viability of this concept. These mechanisms are the location of the account holder set, assignment of peers, access to account holder set information, and maintenance of account holder set. The maintenance mechanisms ensure consistent long-term remote storage of dynamic data in DHT-based p2p
overlays. A special challenge was to find trustworthy access mechanism to remotely stored data in DHT-based p2p overlays. These challenges and mechanisms are covered in Section 4.2.
Trusted peers and the aggregation protocol build the basic concept for building a distributed basis of trust in the token-based accounting scheme. Section 4.3 discusses the selection and organisation of trusted peers. The aggregation protocol requires enhancements in order to ensure rule compliant execution of aggregation tasks in the presence of incentives for defraud. A new mechanism is presented that allows a random selection of a group of trusted peers where the randomness can be verified by any peer afterwards. This prevents collusion. In order to guarantee the secrecy of the scheme’s private key, proactive secret sharing mecha- nisms can be applied. Section 4.5 presents the proactive mechanism that can be applied to the two selected threshold cryptography schemes and analyses the traffic created by these mech- anisms. Section 4.6 uses these findings in order to analyse different strategies for distributing update shares to the trusted peers. Together with the selection of appropriate threshold cryptography schemes performed in Section 3.2.2, this builds a distributed basis of trust in
distributed autonomous systems.
Finally, Section 4.7 discusses how failures occurring during transactions can be handled by the transaction partners.
4.1 Peer Identification
For trustworthy accounting, peers must be clearly and permanently identified. This eliminates poten- tial Sybil attacks (Dou02), whitewashing, and allows for the identification of those who try to cheat, collude, or act maliciously. Therefore, as described in Section 3.1, each peer possesses a private/public key pair issued by some certification authority. This key pair serves as basic peer identification. The certification authority is responsible for guaranteeing that peers will not change their identification, and is also maintaining the appropriate controls thereof.
In order to identify peers in a peer-to-peer overlay network the hash value h = H(P Ki)of the peer i public key P Kp is used. For this, it is assume that H is a one-way secure hash function and that there are no collisions for the peer IDs.