摘要 IPFS(Inter Planetary File System,又称星际文件系统)是一种点对点的分布式文件系统,旨在连接所有有相同的文件系统的计算机设备。在某些方面,IPFS类似于web, 但web 是中心化的,而IPFS是一个单一的Bittorrent 群集,用git仓库分布式存储。换句话说,IPFS提供了高吞吐量的内容寻址块存储模型,具有内容寻址的超链接。这形成了一个广义的Merkle DAG 数据结构,可以用这个数据结构构建版本文件系统,区块链,甚至是永久性网站。IPFS 结合了分布式哈希表,带有激励机制的块交换和自我认证命名空间。IPFS 没有单故障点,节点不需要相互信任。 1. 介绍 在全球分布式文件系统这领域, 已经有许多人的尝试。一些系统已经取得了重大的成功,而很多却完全失败了。在学术尝试中, AFS【6】就是成功的例子,如今已经得到广泛的应用,然而,其他的【7, ?】却没有得到相同的结果。在学术界之外,应用最广泛的是面向音视频媒体的点对点文件共享系统。最值得注意的是,Napster, KaZaA和BitTorrent[2]部署的文件分发系统支持1亿用户的同时在线。即使在今天,BitTorrent也维持着每天千万节点的活跃数。基于这些学术文件系统理论而实现的应用程序有很多的用户量。然而,这些系统理论是在应用层,而没有放在基础层。以致没有出现通用的文件系统基础框架,给全球提供低延迟的分发。 1.托管和分发PB级数据集; 2.跨组织的大数据计算; 3.大批量的高清晰度按需或实时媒体流; 4.大规模数据集的版本化和链接; 5.防止意外丢失重要文件等。 其中许多可以归结为“大量数据,无处不在”。由于关键功能和带宽问题,我们已经为不同的数据放弃了HTTP 分销协议。下一步是使它们成为web自己的一部分。 2.背景 本节回顾了IPFS所采用成功的点对点系统技术的重要属性。 2.1 分布式哈希表(DHT) 分布式散列表(DHT)被广泛用于协调和维护关于对等系统的元数据。比如,Mainline DHT是一个去中心化哈希表,他可追踪查找所有的对等节点。 2.1.1 KADEMLIA DHT Kademlia[10] 是受欢迎的DHT, 它提供: 1.通过大量网络进行高效查询:查询平均联系人O(log2N)节点。(例如,20跳10万个节点的网络) 2.低协调开销:优化数量的控制消息发送到其他节点。 3.抵抗各种攻击,喜欢长寿节点。 4.在对等应用中广泛使用,包括Gnutella和BitTorrent,形成了超过2000万个节点的网络[16]。 2.1.2 CORAL DSHT 虽然一些对等文件系统直接在DHT中存储数据块,这种“数据存储在不需要的节点会乱费存储和带宽”[5]。Coral DSHT扩展了Kademlia三个特别重要的方式: 1.Kademlia在ids为“最近”(使用XOR-distance)的关键节点中存储值。这不考虑应用程序数据的局部性,忽略“远”可能已经拥有数据的节点,并强制“最近”节点存储它,无论它们是否需要。这浪费了大量的存储和带宽。相反,Coral 存储了地址,该地址的对等节点可以提供相应的数据块。 2.Coral将DHT API从get_value(key)换成了get_any_values(key)(DSHT中的“sloppy”)中。这仍然是因为Coral用户只需要一个(工作)的对等体,而不是完整的列表。作为回报,Coral可以仅将子集分配到“最近”的节点,避免热点(当密钥变得流行时,重载所有最近的节点)。 3.另外,Coral根据区域和大小组织了一个称为群集的独立DSHT层次结构。这使得节点首先查询其区域中的对等体,“查找附近的数据而不查询远程节点”[5]并大大减少查找的延迟。 2.1.3 S/KADEMLIA DHT S/Kademlia[1] 扩展了Kademlia, 用于防止恶意的攻击。有如下两方面的方法: 1.S/Kad 提供了方案来保证NodeId的生成已经防止Sybill攻击。它需要节点产生PKI公私钥对。从中导出他们的身份,并彼此间签名。一个方案使用POW工作量证明,使得生成Sybills成本高昂。 2.S/Kad 节点在不相交的路径上查找直,即使网络中存在大量的不诚实节点,也能确保诚实节点可以互相链接。即使网络中存在一半的不诚实节点,S/Kad也能达到85%的成功率。 2.2 块交换 - BitTorrent BitTorrent[3] 是一个广泛成功应用的点对点共享文件系统,它可以在存在不信任的对等节点(群集)的协作网络中分发各自的文件数据片。从BitTorrent和它的生态系统的关键特征, IPFS得到启示如下: 1.BitTorrent的数据交换协议使用了一种bit-for-tat的激励策略, 可以奖励对其他方面做贡献的节点,惩罚只榨取对方资源的节点。 2.BitTorrent对等体跟踪文件的可用性,优先发送稀有片段。这减轻了seeds节点的负担, 让non-seeds节点有能力互相交易。 3.对于一些剥削带宽共享策略, BitTorrent的标准tit-for-tat策略是非常脆弱的。 然而,PropShare[8]是一种不同的对等带宽分配策略, 可以更好的抵制剥削战略, 提高群集的表现。 2.3 版本控制系统- Git 版本控制系统提供了对随时间变化的文件进行建模的设施,并有效地分发不同的版本。流行版本控制系统Git提供了强大的Merkle DAG对象模型,以分布式友好的方式捕获对文件系统树的更改。 1.不可更改的对象表示文件(blob),目录(树)和更改(提交)。 2.通过加密hash对象的内容,让对象可寻址。 3.链接到其他对象是嵌入的,形成一个Merkle DAG。这提供了很多有用的完整和work-flow属性。 4.很多版本元数据(分支,标示等等)都只是指针引用,因此创建和更新的代价都小。 5.版本改变只是更新引用或者添加对象。 6.分布式版本改变对其他用户而言只是转移对象和更新远程引用。 2.4 自我认证认文件系统-SFS SFS [ 12,11 ]提出了两个引人注目的实现(a)分布式信任链,和(b)平等共享的全局命名空间。SFS在创建自我认证文件系统中引进了一种新技术:运用以下策略实现处理远程文件系统: /sfs/<Location>:<HostID>其中Location是网络服务器地址,Host ID = hash(public_key||Location)。因此SFS文件系统的名字认证了它的服务。用户可以通过服务提供的公钥来验证,协商一个共享的私钥,保证所有的通信。所有的SFS实例都共享了一个全局的命名空间,这个命名空间的名称分配是加密的,不被任何中心化体控制。 3. IPFS设计 IPFS是一个分布式文件系统,它综合了以前的对等系统的成功想法,包括DHT,BitTorrent,Git和SFS。IPFS的贡献是简化,发展和将成熟的技术连接成一个单一的内聚系统,大于其部分的总和。IPFS提供了编写和部署应用程序的新平台,以及一个新的分发系统版本化大数据。IPFS甚至可以演进网络本身。 3.1 身份 节点由NodeId标识,这是使用S / Kademlia的静态加密难题[1]创建的公钥的密码散列。节点存储其公私钥(用密码加密)。用户可以在每次启动时自由地设置一个“新”节点身份,尽管这会损失积累的网络利益。激励节点保持不变。 type NodeId Multihash type Multihash []byte // 自描述加密哈希摘要 type PublicKey []byte type PrivateKey []byte // 自描述的私钥 type Node struct { NodeId NodeID PubKey PublicKey PriKey PrivateKey } 基于S / Kademlia的IPFS身份生成: difficulty = <integer parameter> n = Node{} do { n.PubKey, n.PrivKey = PKI.genKeyPair() n.NodeId = hash(n.PubKey) p = count_preceding_zero_bits(hash(n.NodeId)) } while (p < difficulty) 首次连接时,对等体交换公钥,并检查:hash(other.PublicKey)等于other.NodeId。如果没有,则连接被终止。 <function code><digest length><digest bytes> 这允许系统 3.2 网络 IPFS节点与数百个其他节点进行定期通信网络中的节点,可能跨越广域网络。IPFS网络堆栈功能: IPFS将地址存储为多层地址,这个多层地址是由字节字符串组成的, 以便于给底层网络使用。多层地址提供了一种方式来表示地址及其协议,可以封装成好解析的格式。例如: /ip4/10.20.30.40/sctp/1234/ # an SCTP/IPv4 connection proxied over TCP/IPv4 /ip4/5.6.7.8/tcp/5678/ip4/1.2.3.4/sctp/1234/ 3.3路由 IPFS节点需要一个路由系统, 这个路由系统可用于查找: (a)其他同伴的网络地址; (b)专门用于服务特定对象的对等节点。 IPFS使用基于S / Kademlia和Coral的DSHT,在2.1节中具体介绍过。在对象大小和使用模式方面,IPFS类似于Coral[5] 和Mainline[16]。因此,IPFS DHT根据其大小对存储的值进行区分。小的值(等于或小于1KB)直接存储在DHT上。对于更大的值,DHT只存储值索引,这个索引就是一个对等节点的NodeId, 该对等节点可以提供對该类型的值的具体服务。 DSHT的接口如下: type IPFSRouting interface { FindPeer(node NodeId) // 获取特定NodeId的网络地址。 SetValue(key []bytes, value []bytes) // 往DHT存储一个小的元数据。 GetValue(key []bytes) // 从DHT获取元数据。 ProvideValue(key Multihash) // 声明这个节点可一个提供一个大的数据。 FindValuePeers(key Multihash, min int) // 获取服务于该大数据的节点。 } 注意:不同的用例将要求基本不同的路由系统(例如广域网中使用DHT,局域网中使用静态HT)。因此,IPFS路由系统可以根据用户的需求替换的。只要使用上面的接口就可以了,系统都能继续正常运行。 3.4块交换 - BitSwap协议 IPFS 中的BitSwap协议受到BitTorrent 的启发,通过对等节点间交换数据块来分发数据的。像BT一样,每个对等节点在下载的同时不断向其他对等节点上传已下载的数据。和BT协议不同的是, BitSwap 不局限于一个torrent文件中的数据块。BitSwap 协议中存在一个永久的市场。这个市场包括各个节点想要获取的所有块数据。而不管这些块是哪些如.torrent文件中的一部分。这些快数据可能来自文件系统中完全不相关的文件。这个市场是由所有的节点组成的。 3.4.1 - BITSWAP 信用 1.对等节点间会追踪他们的平衡(通过字节认证的方式)。 2.随着债务增加而概率降低,对等者概率的向债务人发送块。 注意的是,如果节点决定不发送到对等体,节点随后忽略对等体的ignore_cooldown超时。 这样可以防止发送者尝试多次发送(洪水攻击)(BitSwap默认是10秒)。 3.4.2 BITSWAP的策略 r = bytes_sent / bytes_recv + 1 根据r,发送到负债节点的概率为: P(send | r ) = 1 ? ( 1/ ( 1 + exp(6 ? 3r) ) ) 正如你看到的图片1,当节点负债比例超过节点已建立信贷的两倍,发送到负债节点的概率就会急速下降。 图片1 当r增加时发送的概率
3.4.3 BITSWAP 账本 type Ledger struct { owner NodeId partner NodeId bytes_sent int bytes_recv int timestamp Timestamp } 节点可以自由的保留分布式账本历史,这不需要正确的操作,因为只有当前的分类账本条目是有用的。节点也可以根据需要自由收集分布式帐本,从不太有用的分布式帐开始:老(其他对等节点可能不存在)和小。 3.4.4 BITSWAP 详解 // Additional state kept type BitSwap struct { ledgers map[NodeId]Ledger // Ledgers known to this node, inc inactive active map[NodeId]Peer // currently open connections to other nodes need_list []Multihash // checksums of blocks this node needs have_list []Multihash // checksums of blocks this node has } type Peer struct { nodeid NodeId ledger Ledger // Ledger between the node and this peer last_seen Timestamp // timestamp of last received message want_list []Multihash // checksums of all blocks wanted by peer // includes blocks wanted by peer's peers } // Protocol interface: interface Peer { open (nodeid : NodeId, ledger : Ledger); send_want_list (want_list : WantList); send_block(block: Block) -> (complete:Bool); close(final: Bool); } 对等连接的生命周期草图: 1.Open: 对等节点间发送ledgers 直到他们同意。 2.Sending: 对等节点间交换want_lists 和blocks。 3.Close: 对等节点断开链接。 4.Ignored: (特殊)对等体被忽略(等待时间的超时)如果节点采用防止发送策略。 Peer.open(NodeId, Ledger). 3.5 Merkle DAG对象 DHT和BitSwap允许IPFS构造一个庞大的点对点系统用来快速稳定的分发和存储。最主要的是,IPFS建造了一个Merkle DAG,一个无回路有向图,对象之间的links都是hash加密嵌入在源目标中。这是Git数据结构的一种推广。Merkle DAGS给IPFS提供了很多有用的属性,包括: type IPFSLink struct { Name string // 此link的别名 Hash Multihash // 目标的加密hash Size int // 目标总大小 } type IPFSObject struct { links []IPFSLink //links数组 data []byte //不透明内容数据 } IPFS Merkle DAG是存储数据非常灵活的一种方式。只要求对象引用是(a)内容可寻址的,(b)用上面的格式编码。IPFS允许应用完全的掌控数据域;应用可以使用任何自定义格式的数据,即使数据IPFS都无法理解。单独的内部对象link表允许IPFS做: 用对象的形式列出所有对象引用,例如: > ipfs ls /XLZ1625Jjn7SubMDgEyeaynFuR84ginqvzb XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x 189458 less XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5 19441 script XLF4hwVHsVuZ78FZK6fozf8Jj9WEURMbCX4 5286 template <object multihash> <object size> <link name> 解决字符串路经查找,例如foo/bar/baz。给出一个对象,IPFS会解析第一个路经成分进行hash放入到对象的link表中,再获取路径的第二个组成部分,一直如此重复下去。因此,任何数据格式的字符串路经都可以在Merkle DAG中使用。 > ipfs refs --recursive \ /XLZ1625Jjn7SubMDgEyeaynFuR84ginqvzb XLLxhdgJcXzLbtsLRL1twCHA2NrURp4H38s XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5 XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z 原始数据结构公共link结构是IPFS构建任意数据结构的必要组成部分。可以很容易看出Git的对象模型是如何套用DAG的。一些其他潜在的数据结构: (a)键值存储 (b)传统关系型数据 (c)数据三倍存储 (d) 文档发布系统 (e)通信平台 (f)加密货币区块。 这些系统都可以套用IPFS Merkle DAG,这使这些系统更复杂的应用可以使用IPFS作为传输协议。 3.5.1 路经 IPFS对象可以遍历一个字符串路经。路经格式与传统UNIX文件系统以及Web一致。Merkle DAG的links使遍历变得很容易。全称路经在IPFS中的格式是: # 格式 /ipfs/<hash-of-object>/<name-path-to-object> # 例子 /ipfs/XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x/foo.txt /ipfs前缀允许只要在挂载点不冲突(挂载点名称当然是可配置的)的情况下挂载到一个已存在的系统上。第二个路经组成部分(第一个是IPFS)是一个对象的hash。通常都是这种情况,因为没有全局的根。一个根对象可能会有一个不可能完成的任务,就是在分布式环境(可能还断开链接)中处理百万对象的一致性。因此,我们用地址可寻址来模拟根。通过的hash所有的对象都是可访问的。这意思是说,给一个路经对象/bar/baz,最后一个对象可以可以被所有的访问的: /ipfs/<hash-of-foo>/bar/baz /ipfs/<hash-of-bar>/baz /ipfs/<hash-of-baz> 3.5.2 本地对象 IPFS客户端需要一个本地存储器,一个外部系统可以为IPFS管理的对象存储以及检索本地原始数据。存储器的类型根据节点使用案例不同而不同。在大多数情况下,这个存储器只是硬盘空间的一部分(不是被本地的文件系统使用键值存储如leveldb来管理,就是直接被IPFS客户端管理),在其他的情况下,例如非持久性缓存,存储器就是RAM的一部分。 最终,所有的块在IPFS中都是能够获取的到的,块都存储在了一些节点的本地存储器中。当用户请求一个对象时,这个对象会被查找到并下载下来存储到本地,至少也是暂时的存储在本地。这为一些可配置时间量提供了快速的查找。 3.5.3对象锁定 3.5.4 发布对象 3.5.5 对象级别的加密 type EncryptedObject struct { Object []bytes // 已加密的原始对象数据 Tag []bytes // 可选择的加密标识 type SignedObject struct { Object []bytes // 已签名的原始对象数据 Signature []bytes // HMAC签名 PublicKey []multihash // 多重哈希身份键值 } 加密操作改变了对象的哈希值,定义一个不同的新的对象。IPFS自动的验证签名以及使用用户指定的钥匙链解密数据。加密数据的links也同样的被保护着,没有解密秘钥就无法遍历对象。也存在着一种现象,可能父对象使用了一个秘钥进行了加密,而子对象使用了另一个秘钥进行加密或者根本没有加密。这可以保证links共享对象安全。 3.6 文件 IPFS在Merkle DAG上还为模型化版本文件系统定义了一组对象。这个对象模型与Git比较相似: (a)快速大小查找(总字节大小已经加入到对象中) (b)大文件的重复删除(添加到list对象) (c)commits嵌入到trees中。不过,IPFS文件对象与Git还是非常相近的,两者之间进行交流都是有可能的。而且,Git的一个系列的对象可以被引进过来转换都不会丢失任何的信息。(UNIX文件权限等等)。 标记:下面的文件对象格式使用JSON。注意,虽然IPFS包含了JSON的互相转换,但是文件对象的结构体还是使用protobufs的二进制编码。 3.6.1 文件对象:BLOB { "data": "some data here", // blobs无links } 3.6.2 文件对象: LIST { "data": ["blob", "list", "blob"], //lists有一个对象类型的数组作为数据 "links": [ { "hash": "XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x", "size": 189458 }, { "hash": "XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5", "size": 19441 }, { "hash": "XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z", "size": 5286 } //在links中lists是没有名字的 ] } 3.6.3 文件对象:TREE "data": ["blob", "list", "blob"],//trees有一个对象类型的数组作为数据 "links": [ { "hash": "XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x", "name": "less", "size": 189458 }, { "hash": "XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5", "name": "script", "size": 19441 }, { "hash": "XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z", "name": "template", "size": 5286 }//trees是有名字的 ] } 3.6.4 文件对象:COMMIT 3.6.5 版本控制 Git版本控制工具的所有功能对于IPFS的用户是可用的。对象模型不完全一致,但也是可兼容的。这可能: 3.6.6 文件系统路径 tree缓存:由于所有的对象都是哈希寻址的,它们可以被无限的缓存。另外,trees一般比较小,所以比起blobs,IPFS会优先缓存trees。 { "data": ["tree", "blob", "tree", "list", "blob" "blob"], "links": [ { "hash": "<ttt222-hash>", "size": 1234 "name": "ttt222-name" }, { "hash": "<bbb111-hash>", "size": 123, "name": "ttt222-name/bbb111-name" }, { "hash": "<ttt333-hash>", "size": 3456, "name": "ttt333-name" }, { "hash": "<lll111-hash>", "size": 587, "name": "ttt333-name/lll111-name" }, { "hash": "<bbb222-hash>", "size": 22, "name": "ttt333-name/lll111-name/bbb222-name" }, { "hash": "<bbb222-hash>", "size": 22 "name": "bbb222-name" } ] } 3.7 IPNS:命名以及易变状态 从某种意义上说:对象就是永恒的 (a)优秀的宽带优化 (b)不受信任的内容服务 (c)永恒的links (d)能够永久备任何对象以及它的引用。 3.7.1 自我认证名称 1.回想一下在IPFS中:NodeId = hash(node.PubKey) 2.我们给每个用户分配一个可变的命名空间,在此路径下:/ipns/ 3.一个用户可以在此路径下发布一个用自己私钥签名的对象,比如说:/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/ 4.当其他用户获取对象时,他们可以检测签名是否与公钥和NodeId匹配。这个验证了用户发布对象的真实性,达到了可变状态的获取。 注意下面的细节: 1.IPNS(InterPlanetary的命名空间)分开前缀是在可变和不可变的路径之间建立一个很容易辨认的区别,为了程序也为了人类阅读的便利。 routing.setValue(NodeId, <ns-object-hash>) 3.发布的对象中任何links在命令空间中充当子名称: /ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/ /ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/docs /ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/docs/ipfs 4.一般建议发布一个commit对象或者其他对象的时候,要使用历史版本记录,因为这样就用户就可以找到之前使用过的名字。不过由于这并不总是需要的,所以留个用户自己选择。 3.7.2人类友好名称 # Alice links 到Bob上 ipfs link /<alice-pk-hash>/friends/bob /<bob-pk-hash> # Eve links 到Alice上 ipfs link /<eve-pk-hash/friends/alice /<alice-pk-hash> # Eve 也可以访问Bob /<eve-pk-hash/friends/alice/friends/bob # 访问Verisign 认证域 /<verisign-pk-hash>/foo.com DNS TXT IPNS 记录 # DNS TXT 记录 ipfs.benet.ai. TXT "ipfs=XLF2ipQ4jD3U ..." # 表现为符号链接 ln -s /ipns/XLF2ipQ4jD3U /ipns/fs.benet.ai Proquint 可读的标识符 Proquint可读的标识符总是会有将二进制编码翻译成可读文件的方法。IPNS则支持Proquint[?].。如下: # proquint语句 /ipns/dahih-dolij-sozuk-vosah-luvar-fuluh # 分解为相应的下面形式 /ipns/KhAwNprxYVxKqpDZ 缩短名称服务 # 用户可以从下面获取一个link /ipns/shorten.er/foobar # 然后放到自己的命名空间 /ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm 3.8使用IPFS IPFS设计为可以使用多种不同的方法来使用的,下面就是一些我将会继续追求的使用方式: 1.作为一个挂载的全局文件系统,挂载在/ipfs和/ipns下 2.作为一个挂载的个人同步文件夹,自动的进行版本管理,发布,以及备份任何的写入 3.作为一个加密的文件或者数据共享系统 4.作为所有软件的版本包管理者 5.作为虚拟机器的根文件系统 6.作为VM的启动文件系统 (在管理程序下) 7.作为一个数据库:应用可以直接将数据写入Merkle DAG数据模型中,获取所有的版本,缓冲,以及IPFS提供的分配 8.作为一个linked(和加密的)通信平台 9.作为一个为大文件的完整性检查CDN(不使用SSL的情况下) 10.作为一个加密的CDN 11.在网页上,作为一个web CDN 12.作为一个links永远存在新的永恒的Web IPFS实现的目标: (a)一个IPFS库可以导出到你自己应用中使用 (b)命令行工具可以直接操作对象 (c)使用FUSE[?]或者内核的模型挂载文件系统【】 4.未来 IPFS的思想是几十年成功的分布式系统的探索和开源的产物。IPFS综合了很多迄今为止很成功的系统中优秀的思想。除了BitSwap新协议之外,IPFS最大的特色就是系统的耦合以及设计的综合性。 5. 感谢 IPFS是一个很多很棒的主意以及系统的综合体。没有站在巨人的肩膀上,IPFS也不可能敢于有一个这么有野心的目标。 6.引用备忘录 7.引用 [1].I. Baumgart and S. Mies. S/kademlia:一个安全的基于秘钥路由的可行方法。2007年国际会议,第2卷,1-8页,在《并发和分布式系统》中。IEEE,2007年。 [7] J. Kubiatowicz, D. Bindel, Y. Chen, S. Czerwinski, P. Eaton, D. Geels, R. Gummadi, S. Rhea,H. Weatherspoon, W. Weimer, et al. Oceanstore: An architecture for global-scale persistent storage. ACM Sigplan Notices, 35(11):190–201, 2000. [8] D. Levin, K. LaCurts, N. Spring, andB. Bhattacharjee. Bittorrent is an auction: analyzing and improving bittorrent’s incentives. In ACM SIGCOMM Computer Communication Review, volume 38, pages 243–254. ACM, 2008. [9] A. J. Mashtizadeh, A. Bittau, Y. F. Huang, andD. Mazieres. Replication, history, and grafting in the ori file system. In Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles, pages 151–166. ACM, 2013. [10] P. Maymounkov and D. Mazieres. Kademlia: A peer-to-peer information system based on the xor metric. In Peer-to-Peer Systems, pages 53–65. Springer, 2002. [11] D. Mazieres and F. Kaashoek. Self-certifying file system. 2000. [12] D. Mazieres and M. F. Kaashoek. Escaping the evils of centralized control with self-certifying pathnames. In Proceedings of the 8th ACM SIGOPS European workshop on Support for composing distributed applications, pages 118–125. ACM, 1998. [13] J. Rosenberg and A. Keranen. Interactive connectivity establishment (ice): A protocol for network address translator (nat) traversal for offer/answer protocols. 2013. [14] S. Shalunov, G. Hazel, J. Iyengar, and M. Kuehlewind. Low extra delay background transport (ledbat). draft-ietf-ledbat-congestion-04. txt, 2010. [15] R. R. Stewart and Q. Xie. Stream control transmission protocol (SCTP): a reference guide. Addison-Wesley Longman Publishing Co., Inc., 2001. [16] L. Wang and J. Kangasharju. Measuring large-scale distributed systems: case of bittorrent mainline dht. In Peer-to-Peer Computing (P2P), 2013 IEEE Thirteenth International Conference on, pages 1–10. IEEE, 2013. 全国服务热线:0577-86779390 公司名称:温州一息科技有限公司 公司地址:浙江省温州市瓯海区温州市数字经济大厦6楼 官网:www.ownipfs.com 一直播ID:1305807669(IPFS星脉矿机) 抖音:一息 西瓜视频:IPFS星脉矿机 微博:温州一息科技有限公司 微信群:添加微信号“VelarMining001”进官方微信群 关注微信公众号“星脉矿机Velar Mining”了解IPFS一手资讯 本文来源:IPFS星脉矿机 —- 编译者/作者:IPFS星脉矿机 玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。 |
IPFS白皮书中文版
2020-04-07 IPFS星脉矿机 来源:火星财经
LOADING...
相关阅读:
- 解析Filecoin与IPFS项目中“头矿”2020-07-31
- 黑犇科技:稳定的存储是Filecoin的基本要求2020-07-31
- 一文了解Filecoin奖励测试网最新信息2020-07-31
- 影响IPFS投资收益的三大因素解析2020-07-31
- 千亿存储市场,IPFS必将加冕为王,如何获取收益最大化?2020-07-31