copy in Brian's post
[Imported from Trac: page NewAccountingDesign, version 1]
parent
0411acb39b
commit
768e77e868
172
NewAccountingDesign.md
Normal file
172
NewAccountingDesign.md
Normal file
|
@ -0,0 +1,172 @@
|
|||
originally from <https://tahoe-lafs.org/pipermail/tahoe-dev/2010-December/005748.html> :
|
||||
|
||||
Each time we cycle around this topic, we chip away at the complexity,
|
||||
prune back some of the loftier goals, haggle for a couple of weeks, then
|
||||
throw up our hands and go back to our day jobs for another couple
|
||||
months.
|
||||
|
||||
This time around, here are the previous lofty goals that I Brian am going to
|
||||
move into the non-goal category:
|
||||
|
||||
- repairer: who pays for the new share?
|
||||
- sub-accounts, delegation, allmydata partners
|
||||
- public webapi node: extending accounting beyond node and through
|
||||
webapi/WUI: when Bob uses a public WUI, how can his shares be
|
||||
counted against his quota instead of the webapi operator's?
|
||||
|
||||
and I want to move a set of things into a "phase 2" category, to be
|
||||
figured out after we get the "phase 1" stuff done:
|
||||
|
||||
- Invitations
|
||||
- transitive introductions
|
||||
- account managers
|
||||
- pay-for-storage
|
||||
- tit-for-tat
|
||||
|
||||
Also, we have a new inspiration: we've been talking a lot about the work of
|
||||
[Elinor Ostrom](http://en.wikipedia.org/wiki/Elinor_Ostrom), who has written a
|
||||
lot about communities who successfully manage common resources without suffering
|
||||
from the well-known "Tragedy Of The Commons". She established a set of principles
|
||||
that these communities had in common:
|
||||
|
||||
1. Clearly defined boundaries (effective exclusion of external
|
||||
unentitled parties);
|
||||
2. Rules regarding the appropriation and provision of common
|
||||
resources are adapted to local conditions;
|
||||
3. Collective-choice arrangements allow most resource appropriators
|
||||
to participate in the decision-making process;
|
||||
4. Effective monitoring by monitors who are part of or accountable to
|
||||
the appropriators;
|
||||
5. There is a scale of graduated sanctions for resource appropriators
|
||||
who violate community rules;
|
||||
6. Mechanisms of conflict resolution are cheap and of easy access;
|
||||
7. The self-determination of the community is recognized by
|
||||
higher-level authorities;
|
||||
8. In the case of larger common-pool resources: organization in the
|
||||
form of multiple layers of nested enterprises, with small local
|
||||
CPRs at the base level.
|
||||
|
||||
In the Tahoe context, that means that the participants of a given grid
|
||||
(both clients using storage and servers providing storage) should have a
|
||||
lot of information about who is using what on where, and should have
|
||||
control over that space (being able to say no). There should be some
|
||||
obviously public broadcast channels, so everybody knows that everybody
|
||||
else knows who is using what.
|
||||
|
||||
So, in my current line of thinking, an Accounting Phase 1 is looking
|
||||
like this:
|
||||
|
||||
*** tahoe.cfg:storage gets some new flags:
|
||||
- accounting=enabled
|
||||
- this turns on the lease-owner DB. Existing shares are marked
|
||||
'anonymous'. New shares that arrive through the old
|
||||
RIStorageServer interface are labeled according to the TubID of
|
||||
the other end of the connection. New shares that arrive through
|
||||
the new RIAccountableStorageServer interface are labeled
|
||||
according to the account under which that interface object was
|
||||
created (see below).
|
||||
- accounting=required
|
||||
- this reads "storage-accounts.txt" for a list of accounts. Each
|
||||
contains a pubkey, a petname, and maybe some additional
|
||||
information (either local notes, or self-describing data sent by
|
||||
the privkey holder)
|
||||
- the RIStorageServer interface no longer accepts shares. Only
|
||||
RIAccountableStorageServer accepts them.
|
||||
|
||||
*** tahoe.cfg:client gets some new flags
|
||||
- actually it needs to be in private/ somewhere
|
||||
- add a privkey. If present, clients will connect to
|
||||
RIStorageServer, then attempt to upgrade to
|
||||
RIAccountableStorageServer by sending a signed upgrade request
|
||||
- clients do all their storage ops through the
|
||||
RIAccountableStorageServer, which causes their shares to be
|
||||
labeled
|
||||
- RIAccountableStorageServer also includes get-my-total-usage
|
||||
methods
|
||||
|
||||
*** the welcome page gets a new control panel
|
||||
- not sure if it needs to be user-private or not
|
||||
- storage-server panel:
|
||||
- contains lists of accounts that are consuming your storage
|
||||
- if accounting=required, add buttons to freeze/thaw the account,
|
||||
cautious button to delete all shares
|
||||
- client panel:
|
||||
- contains lists of servers that are holding your shares
|
||||
- combo "grid" panel:
|
||||
- contains both, correlated
|
||||
|
||||
*** maybe broadcast channel of activity
|
||||
- daily, maybe at first hourly digest of aggregate usage
|
||||
- "Bob uploaded 62MB of data". "Alice downloaded 146MB of data"
|
||||
- "Bob is currently using 3.5GB of storage space"
|
||||
- "Alice is currently hosting 4.2GB of shares and has 0.8GB free"
|
||||
- also include new-server, new-client events
|
||||
- "Carol joined the grid, offering 3.0GB of storage space"
|
||||
- "Dave invited Edgar to join the grid"
|
||||
- and server-admin actions
|
||||
- "Carol froze Bob's shares: dude, you're using too much"
|
||||
- "David deleted Alice's shares: you unfriended me on facebook so
|
||||
I'm deleting all your data"
|
||||
- also generalized chat
|
||||
- "Bob says: anyone up for pizza tonight?"
|
||||
|
||||
*** storage server needs a new crawler
|
||||
- or the existing [LeaseCrawler](LeaseCrawler) needs some new features
|
||||
- shares contain canonical lease info, but local
|
||||
who-is-consuming-what and remote get-my-total-usage methods need
|
||||
pre-generated totals
|
||||
- once usage DB is complete, new shares are added at time of upload
|
||||
- but we must be able to generate/regenerate usage DB from just the
|
||||
shares (er, just shares plus table of ownerid->account data, since
|
||||
share.lease.ownerid field is too small)
|
||||
|
||||
*** RIStorageServer gets new upgrade method
|
||||
- accepts a signed request, returns RIAccountableStorageServer facet
|
||||
- request needs to be scoped correctly: server1 should not be able
|
||||
to get Alice's facet on server2. Request should include serverid.
|
||||
- for transitive introductions, request may also contain
|
||||
recommendations / certchains / introduction path
|
||||
- upgrade method may fail when server doesn't like the client
|
||||
- might be a temporary failure: the upgrade request might get
|
||||
elevated to the storage server admin for approval. Might want "try
|
||||
again later (at time=T)" response code.
|
||||
- storage requests to RIAccountableStorageServer might fail if
|
||||
server-admin freezes or cancels the account. get-my-total-usage
|
||||
should keep working in many cases.
|
||||
|
||||
The general idea is that new (accounting-aware) clients will use a new
|
||||
storage-server object, one which is dedicated just to a specific account
|
||||
(as defined by an ECDSA pubkey), which will keep track of how much
|
||||
they're using. To access the new object, they'll submit a signed request
|
||||
to some publically-visible object (either the old RIStorageServer FURL,
|
||||
or a new account-desk FURL published next to the old one in the #466
|
||||
dict-based announcement). The new object will also have methods to query
|
||||
current usage. Clients ought to keep track of how much they've uploaded
|
||||
to servers, but since they haven't ever done this in the past, it may be
|
||||
hard to get an accurate count without relying upon each server.
|
||||
|
||||
The Introducer will also need to help create the broadcast channel,
|
||||
either by presenting broadcast messages as Announcements, or by running
|
||||
a pubsub service directly.
|
||||
|
||||
|
||||
If we complete this, and we implement some small UI/tahoe.cfg for it, I
|
||||
think we'll have a good starting point for friend-net grids:
|
||||
|
||||
- each client will generate a keypair at startup
|
||||
- all shares (well, all leases) will be associated with a specific
|
||||
client (with a nickname)
|
||||
- servers will accept shares from anybody, but they'll have a table of
|
||||
who is using how much. An attacker can still create thousands of
|
||||
throwaway accounts, but it'll be obvious that this is going on. In
|
||||
the non-attacker case, all participants will be able to view how
|
||||
space is being used by each other.
|
||||
|
||||
Then we can start to figure out the not-so-friendly grids, where you
|
||||
don't accept data from just anybody. To get there, we'll need to start
|
||||
with explicitly-configured whitelists (a list of client pubkey
|
||||
identifiers who can store data, and nobody else is accepted), and then
|
||||
quickly move to a better (i.e. more automatic) workflow like Invitations
|
||||
or Account Managers or something. Eventually that may get us back to
|
||||
more traditional economics where a node can accept money of some sort
|
||||
(BTC!) to enable storage for a given client.
|
Loading…
Reference in a new issue