[Mnet-devel] PET 2004: 5 minute rump session talk
Zooko
zooko at zooko.com
Wed May 26 16:49:36 BST 2004
These are the notes I wrote for what I intend to say at the rump
session on Thursday. I've practiced it a couple of times, and it
clocks in at just under 5 minutes.
--Z
I. Intro
Mnet is a decentralized filesystem, comparable to Freenet, OceanStore,
and GNUnet. The goal of Mnet is to be useful to lots of real-world
users as a self-organizing, attack-resistant virtual space in which to
store files.
In the next 4 minutes I will describe the basic architecture of the
Mnet filesystem. In the remaining minute, I will point out a basic
assumption that we relied upon when designing Mnet that I would like to
see challenged in order to open up the way for future systems of this
kind.
II. How it works
A. In Mnet, every node knows about every other node. This is obviously
non-scalable, as it implies a cost on each node which is proportional
to the size of the whole network. However for cases where the network
is not too large, this design seems to offer excellent performance,
flexibility, and robustness.
B. Every node generates an RSA keypair. All communications are
encrypted and authenticated using these keys (using a hybrid
cryptosystem for efficiency). Each node has a "nodeId" which is the
SHA1 hash of its public key.
C. To store a file on Mnet, you perform four steps:
1. Erasure code, generating 3 parity blocks for every data block of
the file.
2. Encrypt the blocks (both original data blocks and parity blocks)
using a symmetric encryption key of your choice.
3. Let the SHA1 hash of the encrypted block be the "blockId". Now
send each encrypted block to the node whose nodeId is closest to the
blockId in some metric.
4. Now you have a list of blockIds. Call this list the "inode".
Treat the inode exactly like you treat data blocks: encrypt it and
store it on the node whose nodeId most closely matches the inode's
blockId.
Now the blockId of the inode, plus the symmetric encryption key, is
necessary and sufficient for anyone to retrieve the blocks and
reconstruct the original contents of the file.
III. Assumption
A basic assumption that we made in the design of Mnet is that there
will be a single large network comprising all of the users, who are
"cooperating strangers". I would like to learn about the consequences
of alternative assumptions. Two alternatives that come to mind are
"Friend-of-a-Friend" networks like a decentralized version of
Friendster, and "clubs" where there are many small networks, and all
participants in a single network are socially related as being members
of the same group. George Danezis has recently published a paper which
explores these very ideas.
More information about the Mnet-devel
mailing list