[p2p-hackers] Trust Inflation / Deflation
Alen Peacock
alenlpeacock at gmail.com
Thu Mar 17 15:52:27 UTC 2005
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.
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.
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'.
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.
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'.
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?
Alen
[1] http://gnunet.org/download/ebe.ps
More information about the P2p-hackers
mailing list