Skip to Content.
Sympa Menu

bluesky - Re: The Grapevine Project

bluesky AT lists.ibiblio.org

Subject: Global-Scale Distributed Storage Systems

List archive

Chronological Thread  
  • From: Stephen Blackheath <stephen AT blacksapphire.com>
  • To: Global-Scale Distributed Storage Systems <bluesky AT franklin.oit.unc.edu>
  • Subject: Re: The Grapevine Project
  • Date: Thu, 6 Dec 2001 13:32:54 +1300


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 06 Dec 2001 13:05, Wei Dai wrote:
> Welcome to the list. Since you were inspired by Freenet, can you tell us
> what problems you saw with Freenet, and how your approach solves them?

Certainly. The biggest problem with Freenet is maintaining the coherency of
the network. There are lots of possible approaches to this. Grapevine could
be considered to be one of those approaches, or it could be considered
completely different.

Grapevine and Freenet both work by the '6 degrees of separation' theory: If
you have 100 neighbours, say, and the network has 1,000,000 nodes, then in an
optimally connected network, you should be able to get to any point in 3 hops.

Freenet is self-organizing, in that the connection of nodes dynamically
changes. In practice, it doesn't organize all that well, and it can take
tens of hops to retrieve a file. Grapevine has a more rigid structure, which
sounds bad, but it gives near-optimal connectivity. It also gives better
security, because it severely limits the number of neighbours you can
discover, thus protecting against 'harvesting attacks'.

> Does Grapevine fit into the "three services" model I described at
> http://www.mail-archive.com/bluesky%40franklin.oit.unc.edu/msg00012.html?

Let me have a look...

Yes, it does. Let me briefly describe how it accomplishes each service.
Some of this may not make sense if you don't understand some of our
underlying assumptions:

1. name lookup service: We want to map a name to a content-hash key (CHK).
So, we hash that name and send it as a request. Because we require an
authoritative answer to the question, we send the request to the most
"trusted" nodes. There is an issue of file ownership, but to cut a long
story short, it gets mapped to a CHK. How do we determine what nodes are
"trusted"? This depends on the previously briefly described SAHP algorithm
which achieves the following: If you have a "high" SAHP value, then this
proves that you expended a large amount of CPU time to arrive at your
location in the network. That is, it is unlikely that you chose your own
"location" in the network. Nodes with high SAHP values will find it most
difficult to collude, because it is extremely expensive to get a collection
of them in the any target region of space.

2. data location service: Data location is the main part of the design.
Just apply the routing algorithm, and you locate the data. The routing
algorithm is very simple - route to the neighbour nearest to your target key.

3. data transport service: Like Freenet, the answer comes back along the
request path, with a certain minimum amount of proxying to protect the
anonymity of the 'server'. Usually it will be proxied only once, so that it
does not waste too much network bandwidth.

> On Wed, Dec 05, 2001 at 06:35:41PM -0500, Stephen Blackheath wrote:
> > Hello everyone,
> >
> > I just found out about this mailing list and I thought I'd better
> > introduce my project - The Grapevine Project
> > (http://www.grapevineproject.org/).
> >
> > Briefly, it's a decentralized network with goals of global scalability,
> > efficiency, anonymous publishing, and resistance to denial-of-service
> > attacks.
> >
> > I was originally inspired by Freenet. In June I started having ideas of
> > a new way to approach the problem, and since it was different enough from
> > Freenet, I thought I would start a new project. Right now the design is
> > largely complete, and we're in the early stages of development.
> >
> > In terms of things you know, the routing is a cross between the
> > Content-Addressable Network and Freenet. We use a 'hash cash' technique
> > (which we call "Solve A Hard Problem") for defence against
> > denial-of-service attacks - the assumption being that legitimate nodes
> > have more CPU power than attackers.
> >
> > We have strategies to get good use out of nodes that are only connected
> > for a short time (i.e. dial-up). We have strategies to deal with the
> > 'karmic debt' problem - where a node should not take more than it
> > contributes. We also hope to employ some mix-net strategies and
> > reputation strategies, but those are not finalized.
> >
> > Everything is on the website, but we still need to write a good technical
> > summary.
> >
> >
> > Steve
> >
> > ---
> > You are currently subscribed to bluesky as: weidai AT eskimo.com
> > For list information visit http://www.transarc.ibm.com/~ota/bluesky/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8Dry27I0ehz47OHERAir6AJ9hYWav+5Yy3yBWNeBTmS9ssam2ZACePoFX
azah/Z45iXO1/vknI6tuIvU=
=3h0b
-----END PGP SIGNATURE-----




Archive powered by MHonArc 2.6.24.

Top of Page