<div dir="ltr">attending:  amiller, daira, juan, vitalik, nathan, za, zooko<br><br>Zooko started with a Layered Architecture perspective on tahoe using bits of<br>this presentation:<br><br><a href="https://tahoe-lafs.org/~zooko/RealWorldCrypto2014/build/slides/#15">https://tahoe-lafs.org/~zooko/RealWorldCrypto2014/build/slides/#15</a><br><br>Layers:<br>~~~~~~~<br><br> 0.  Storage<br> 1.  Network<br> 2.  Routing<br> 3.  Agoric (Social/Economic)<br><br>note: agoric layer at the top which is not implemented<br><br>Layer 0, Data Storage and Security:<br>-----------------------------------<br><br> The guiding principle for this layer is that references and authorities are<br> unified as "capabilities".<br><br> Data stored in tahoe is either "mutable" or "immutable".<br><br> Both types are associated with a set of 'diminishing' capabilities, where<br> for "mutable" data there exists a "write capability" a "read capability" and<br> a "verifying capability".  These capabilities are orderd from strongest to<br> weakest and weaker capabilities are derivable from stronger ones, but not<br> vice versa.<br><br> Immutable data does not have write capabilities.<br><br>Immutable Capability Implementation Details:<br>''''''''''''''''''''''''''''''''''''''''''''<br><br>The following is mainly a summary of the detail in this reference:<br><br> <a href="http://eprint.iacr.org/2012/524.pdf">http://eprint.iacr.org/2012/524.pdf</a><br><br> 0. verify capability contents:<br><br>    * a sha256d of:<br><br>      0. the root of a merkle tree over the cyphertext<br>      1. the root of a merkle tree over the erasure coded shares<br><br> 1. read capability contents:<br><br>    0. the verify capability<br>    1. the symmetric encryption key used to encrypt the file<br><br><br>Mutable Capability Implementation Details:<br>''''''''''''''''''''''''''''''''''''''''''<br><br> 0. verify capability contents:<br><br>    0. a sha256d of the public verification key from the signing key-pair<br>    1. a merkle tree over the shares<br><br> 1. read capability contents:<br><br>    0. the verify capability<br>    1. sha256d of the private signing key from the signing key-pair (see next<br>      capability) (you can derive the encryption key from this)<br><br> 2. read-write capability contents:<br><br>    0. the verify capability<br>    1. sha256d of the private signing key from the signing key-pair<br>    2. the AES-CTR encrypted signing key from the signing key-pair<br><br><br> An interesting property is that one RSA authenticates the clear text after<br> decryption, to prove the write secret was held by the encrypter.<br><br>  Daira notes: "Use a discrete log system should be used for this because of<br>  its efficiency."<br><br><br>Layer 1, Network Layer:<br>-----------------------<br><br> An overview of the fundamental topology of a tahoe grid:<br><br>  <a href="https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/network-and-reliance-topology.svg">https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/network-and-reliance-topology.svg</a><br><br> The most common interface to tahoe:<br><br>  <a href="https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/frontends/webapi.rst">https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/frontends/webapi.rst</a><br><br><br>* Nathan: Note that CAPS in tahoe depend on the network layer in some cases?<br>  There is/Is there layering conflation/violation?<br><br>* Daira:  Current interfaces between the crypto and network layers are not<br>  cleanly separated. Write enablers formerly derived from storage_server<br>  TUBID, now it's simply a shared secret.  Also formerly lease renewal IDs.<br><br>I am unsure whether the answer to Nathan's question was:<br><br>  * "No, capabilities are now generated independently of networking layer data."<br><br>OR:<br><br>  * "Yes, though we've removed the conflation from write-enablers, some<br>    issues still remain."<br><br><a href="https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/frontends/webapi.rst">https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/frontends/webapi.rst</a><br><br>There are plenty of problems with the tahoe network protocol.<br><br>Layer 1a, Cloud Backend:<br>------------------------<br><br>Daira: The bottom 2 nodes depicted in the network-and-reliance-topology.svg<br>are part of the cloud-backend, which interfaces with standard cloud storage<br>provider APIs, to use them as tahoe storage nodes.<br><br><a href="https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/specifications/backends/raic.rst">https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/specifications/backends/raic.rst</a><br><br>Note the bottom two nodes in the network-and-reliance-topology.svg.<br><br>Layer 2, DHT/routing:<br>---------------------<br><br>All-to-all:<br>'''''''''''<br><br>every client attempts to be aware of every servers' state.<br><br>Server selection:<br>'''''''''''''''''<br><br>is based on a random permutation of the servers which is a<br>function of the data being transferred. <-- This is called rendezvous<br>hashing.  Brian starting using it 7 years ago.<br><br><br>Layer 3, Agoric:<br>----------------<br><br>This term was coined by Mark Samuel Miller<br><br>Amiller: Are there examples of projects using only Layer 0?<br>Zooko:   No. People should/could innovate on the DHT layer, and keep the network layer.<br><br><br>Accounting:<br>'''''''''''<br><br> Problem:<br><br>  When a client asks to up/down-load, there's no current tracking of<br>  transactions.<br><br> Solution:<br><br>  Each storageserver keeps a record of which requests have been made.<br>  As a function of requests (or other factors) storageservers implement<br>  economic policies<br><br>  Nathan:   There is certainly not a clean separation from layer 2 here.<br><br>  Daira:  How was this done at MojoNation?<br>  Zooko:  Believed that the Agoric layer was the failing of MojoNation.  Had a<br>          rolling second-price auction.<br><br>           - on request:  start a timer<br>           - if timer runs out:   honor request<br>           - elif other request comes in: do something else<br><br>  Nathan: What about simpler accounting just for simple use-cases?<br><br>   <a href="https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Ostrom">https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Ostrom</a><br><br><br>How does IPFS actually work?<br>----------------------------<br><br>Name:<br>'''''<br>Juan: Originally galactic filesystem.  But GFS was taken.<br><br>So now it's the InterPlanetary File System (IPFS)<br><br>Motivation:<br>'''''''''''<br><br>Juan wanted to come up with a different way of soing static file<br>distribution.<br><br>Specifically he wanted to share really large scientific datasets across<br>network:<br><br> git+bittorrent<br><br>The files of interest were too large for git, so it seemed that rolling<br>checksums, or splitting large file into smaller chunks would be a good approach.<br><br>a bunch of things fell out:   merkle-DAG, merkle-tree<br><br>Address every file using unique addresses, content addressable.<br><br>Designed to be used by web-browsers.<br><br>A globally viewable resource runs afoul of browser same-origin-polcies.<br><br>Solution: Only execute files that are linked to from a prefix of the path.<br><br>Content Addressed P2P filesystem, connect all computers on planet.<br><br>DNS(name) --> IP..   not content addressed.<br><br>bittorrent -- git -- IPFS<br><br>network -- routing -- transport (TCPfirst) --<br><br>naming--mdag <--> same a LASS<br><br>IPFS routing:<br>'''''''''''''<br><br>PUT and GET values, and peers<br><br>Disorganized Snippets:<br>''''''''''''''''''''''<br> <br>bittorrent east to start sharing sdata and try to<br><br>Nathan:  I really like the name.<br>Daira:   How does IPFS do mutability, versioning...  ?<br><br><br>Next Week, Proof of Stake Algorithms in Cryptocurrencies, 2014-10-09:<br>---------------------------------------------------------------------<br><br>Links for Proof of Stake<br><br><a href="http://eprint.iacr.org/2014/452.pdf">http://eprint.iacr.org/2014/452.pdf</a><br><a href="https://docs.google.com/a/buterin.com/document/d/1Bwmy-WZxSXNTaPBgY92kJi2hi_Aa7ro5HfkgUYoRc-Y/edit">https://docs.google.com/a/buterin.com/document/d/1Bwmy-WZxSXNTaPBgY92kJi2hi_Aa7ro5HfkgUYoRc-Y/edit</a><br><a href="https://download.wpsoftware.net/bitcoin/alts.pdf">https://download.wpsoftware.net/bitcoin/alts.pdf</a><br><a href="https://docs.google.com/a/leastauthority.com/document/d/1irOyVlKll6XDKp_oOx1UZGNaqI8ao7ETRgEIepUBh4c/edit#heading=h.q84gnbxqtt6x">https://docs.google.com/a/leastauthority.com/document/d/1irOyVlKll6XDKp_oOx1UZGNaqI8ao7ETRgEIepUBh4c/edit#heading=h.q84gnbxqtt6x</a><br><br><br>Week After That, IPFS 2014-10-16:<br>---------------------------------<br><br>IPFS Link<br><br><a href="http://static.benet.ai/t/ipfs.pdf">http://static.benet.ai/t/ipfs.pdf</a><br><br clear="all"><br>-- <br>-- ظ
</div>