gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Trust Inflation / Deflation


From: Christian Grothoff
Subject: Re: [GNUnet-developers] Trust Inflation / Deflation
Date: Tue, 22 Mar 2005 16:01:18 -0500
User-agent: KMail/1.7.2

On Tuesday 22 March 2005 12:07, Alen Peacock wrote:
> I recently posted the following in the p2p-hackers mailing list:
>
> I've been considering the implementation of a system that uses an
> economic model similar to GnuNet's Excess-Based Economic Model [1],
> but I'm a bit stuck on one point not mentioned in the paper: Trust
> Inflation / Deflation.

Quoting from the referenced article:

> Quick [and therefore unjust] summary of their system: Each node in the
>network maintains a record of its own trust of the other nodes,
>represented as a positive integer.  Nodes that a node knows nothing
>about score 0.  When nodes generate requests they include a priority,
>which translates to the amount the responder may decrement the
>requestor's trust.  While resources are idle, nodes don't "debit" the
>priority amount against earned trust.  When they are busy, they do
>(whether responding or not).  When a response is received, a node
>increments trust in the responder.

>So, imagine a network of well-behaved nodes.  Requests generated in
>the network are destined almost equally among the nodes.  And it just
>so happens that they all generate requests at an aggregate rate below
>some threshold such that resources never become scarce (all nodes are
>in their 'idle' state), so trust is constantly incremented, never
>decremented.  The trust that each node has in the other nodes is
>steadily rising. This goes on for some months.

>Now assume that at some point traffic increases.  Nodes will begin
>charging against priority as they become busy.  If all nodes
>maintained their default request priorities, there would be no
>ordering, so nodes deduce that they must have excess trust in the
>network and start upping the priorities of their outgoing requests.

Not quite.  At the point where the traffic increases and resources are no 
longer available in excess nodes will need to drop requests.  So peers that 
send out requests with a priority that is "too low" will find that their 
requests get dropped (in that they don't get a response).  The strategy (that 
is always there) is to increase the priority if the previous priority did not 
suffice.  Now peers that have accumulated enough trust will see their 
requests eventually succeed (possibly after a few iterations of increasing 
the priority) whereas other nodes (in particular those that contributed very 
little) may increase their 'requested priority' but since their effective 
priority (how much the receiver trusts them) is not sufficient this will not 
allow them to get any response.

>What metrics does a node use to determine the priority value of a
>request?  Should it normalize by the highest trust it has in some
>other node[s]?  Should it observe the 'market value' of request
>priorities arriving locally and try to match?  Any up adjustment to
>the start condition default value could be considered 'trust
>inflation'.

Capping at the trust-level of other nodes makes no sense, since the records of 
the node maybe inadequate and also those levels maybe totally irrelevant.  In 
GNUnet, we limit outgoing priorities to a range within a constant factor of 
the observed average of requests that we receive (something like 2 * 
(1+avg-received)).  This ensures that our outgoing priorities are 'plausible' 
and competitive.  If the average item is sold for X, it does not help to 
offer 100 * X  -- in particular since you trust-score is so bad that you're 
not good for X/2.  GNUnet nodes do not try to "guess" on their popularity 
(trust rating) with other nodes.

>Consider the plight of a new node that just joins the network after
>all this excess trust has accumulated.  Such a node may correctly
>assume that the network does not yet have much trust in it, but if
>'trust inflation' has run rampant, it will have no way of knowing that
>it won't stand a chance of getting resources until it has spent an
>extraordinary amount of its own resources earning enough trust (to
>make up for the months when it didn't exist in the network), because
>it can only assign low priorities to requests.  I suppose that if
>resources are 'in excess' most of the time, this doesn't matter, since
>no one will debit trust.

Not true.  If the existing nodes would actually raise the priorities in the 
network to such extremely high values, the new node would only have to do 
very little to earn trust quickly (since fullfilling any of these requests 
would earn it a lot immediately).  However, it is unlikely that the amount of 
trust put into queries ever bubbles up like that, since, as described before, 
nodes try to minimize the amount of trust offered in order to make it just 
high enough to be above the threshold at which responders would drop the 
query to satisfy other requests.

>So the opposite case might be more interesting.  As more nodes join a
>network, it can be expected to become more busy with requests, and
>eventually, nodes reach a point in which they are in the idle state
>less often than the busy state. After this point, trust no longer
>accumulates, but becomes scarce (because for the majority of the time,
>nodes are debiting trust).  As this continues, all nodes on average
>have very low trust, and it becomes difficult to distinguish
>well-behaving nodes from misbehaving ones.  I'd call this 'trust
>deflation'.

Well, you assume that when more nodes join the network it has to become more 
busy.  However, more nodes also means more resources.  Now, yes, the network 
may not scale linearly, but the economy cannot solve basic scalability 
issues: if the network does not scale to a certain size, lots of requests 
will have to be dropped once the network grows beyond that size.  And if that 
is the case, having enough trust to guarantee performance in a network where 
most of the time requests are dropped will have to be a scarce occurrence 
(but it can still be earned by answering requests by others, so the economy 
is not disabled per-se).

>It seems like there needs to be some sort of way to enforce
>equilibrium in such a system.  Is there, and I just missed it?

I think the answer is that self-interest (pick lowest trust required to get a 
response with reasonable probability) and network load (determined by 
protocol and other network properties) will result in the formation of what 
you may call an equilibrium (of price/trust).

Christian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]