Tesla Coils & Corpses, 2014-08-22 — cryptocurrency 2.0 storage, Ethereum

[Daira Hopwood]

On 22/08/14 21:19, Zooko Wilcox-OHearn wrote:
> Daira finds these systems difficult to think about because they are
> *almost* capabilities-as-data systems except that the mailbox
> addresses are not secret.
> 
> Andrew wonders if you could layer capabilities on top by having a
> little table of which contract is allowed to send messages to which
> contract.
> 
> Zooko says that would be a C-list, implementing a capabilities-as-access system.
> 
> So Andrew went and implemented one right at that moment:
> <https://gist.github.com/amiller/dab7b9d2aece26f5bf20>
> 
> Zooko noticed that it had a flaw — it allowed Alice to give a
> Bob-reference to Carol even if Alice didn't have a reference to Carol.
> 
> Caps-as-access can implement the *-property, and confinement in
> general, Caps-as-data can't.
> 
> Daira says "I think I've been convinced that it is possible to
> implement an obj-caps system in Ethereum."
> 
> Andrew wants to be able to connect two objects within the ocap graph
> even if neither created the other, and there is no path through the
> ocap graph that connects them. Why? Because Andrew might already own
> some Ether, and there could be an Capthereum-based club, like a
> lottery, and Andrew might want to play their lottery.
> 
> We proposed a hybrid in which some sorts of things in Ethereum-world [
> * ], which have private keys, can register themselves with the
> Introducer in order to linked in to the ocap graph, but other sorts of
> things, that created by contracts, through the cap-manager, can't do
> that and so they can be confined.

That's not quite right. In the hypothetical system we were considering at
that point, there were logically two distinguished contracts: a "cap manager"
contract that would be responsible for creating new contracts representing
objects in the obj-cap system and for maintaining C-lists when messages are
sent, and an "introducer" contract responsible for mapping between obj-caps
and caps-as-data. (An implementation might combine these, but doesn't have
to. At the obj-cap level of abstraction, the introducer would be just another
object.)

The introducer is only necessary if you actually want to have caps-as-data;
only the cap manager is necessary to support the obj-cap system (along with
some contracts that opt into using that system).

-- 
Daira Hopwood ⚥

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20140824/22880b6f/attachment.pgp>