NDN研讨会:IPFS体系结构的高级概述

2020-06-30 18:07:58

 IPFS和NDN拥有相同的愿景,即内容可寻址网络的愿景,但是从截然不同的角度来对待它。NDN是本机网络层方法,而IPFS是应用程序层方法。

  ResNetLab受邀向命名数据网络联盟展示“ IPFS体系结构的高级概述” !

  命名数据网络项目是信息中心网络领域的旗舰项目,该项目正在构建一个网络层,以信息为中心(即内容可寻址)的协议栈。它始于大约十年前,由美国10所大学合作,由NSF资助。


IPFS


  IPFS和NDN拥有相同的愿景,即内容可寻址网络的愿景,但是从截然不同的角度来对待它。NDN是本机网络层方法,而IPFS是应用程序层方法。


  鉴于项目的共同愿景,我们对演示非常兴奋,尤其是讨论和反馈。共有20多人参加了此次演讲。

  以下是在演示过程中提出的问题的摘要,以及一些供将来读者使用的答案和指示。您还可以观看完整的录音,并查看幻灯片。

  谈话中出现的问题:


  :块大小是多少?用户可以使用不同的块大小吗?

  答:使用的默认块大小为256 KB。是的,用户/应用程序可以使用ipfs add命令的-s(–chunker)选项来定义块的大小以及块算法。


  :Merkle-Tree是如何创建的?

  答:Merkle-DAG结构(称为行星际链接数据或IPLD))是在用户将文件添加到其本地IPFS节点时在本地创建的。在IPFS网络中发布文件时,该文件不会在其他节点中复制。这是有意进行的,以避免在未经同级同意的情况下将内容添加到同级本地存储。取而代之的是,文件最初由对等方分发,并根据请求将其发布到网络。然后,从原始提供者检索文件的任何节点也可以充当文件的提供者,从而为内容创建缓存网络。在将文件发布到网络时,“提供者记录”会放在DHT中以指向本地节点进行检索。如果网络中的其他对等方希望成为文件的永久提供者,则也可以“固定”文件。如果他们没有固定文件,那么文件最终将被“垃圾收集”。


  :从体系结构的角度来看,如何将文件添加到系统中?特别是,您如何让全世界知道您添加了什么以及位置在哪里?同样,我如何知道其他人已添加到系统中?

  答:IPFS体系结构中没有任何机制可以跟踪发布到网络的文件。让全世界知道新添加的内容/ CID必须在“带外”发生。该主题与IPFS社区中正在进行的有关“分散式搜索引擎”的讨论(请参阅IPFS论坛[1] [2]中的相关讨论)有很大关系,但是迄今为止,还没有任何实质性的成果。就是说,这个话题对协议实验室和整个社区都非常感兴趣。

  行星际命名系统(IPNS,下面将详细讨论)及其支持的PubSub协议(将命名条目传播到订阅了相应IPNS主题的条目)是传播有关新发布内容的信息的另一种方法。应用程序可以利用此选项在应用程序本身的领域内传播(即推送)有关新发布内容的信息。当IPNS在DHT上运行时,它也可以基于请求的方式工作。


  :我是否需要完整的Merkle树结构才能检索其中的一部分?如果我只想检索文件的一部分,则根CID似乎还不够。

  答:用户不需要具有Merkle-DAG的整个结构即可检索其中的一部分。为了仅检索Merkle-DAG的一部分(由一个或多个块CID组成),用户需要具有这些特定的CID。此外,您可以使用根CID和路径符号来访问Merkle-DAG中的文件,例如Qmcri6S86LuivUY4FDcM1phu5REXcFYootxn1GsRoqnFN5 / path / to / some / file.png。


  :一旦为块分配了CID,该块是否不变?

  答:是的,一旦计算出块/块的CID,它将永远保持不变。这是“永久Web”的概念,在SVN,git等版本控制系统中众所周知。我们认为这是存储和交付系统的重要属性。当然,该块本身并不是一成不变的,可以对其进行更改。但是,新文件的CID将与旧文件不匹配,因此必须单独添加新版本(除非内容是通过IPNS在公共密钥下发布的)。


  :如何从IPFS网络撤消CID?

  答:这样的CID是永久性的,不能被“撤消”,因为它是特定内容的哈希值(请参见上面“永久性Web”的注释)。不再希望提供对某些内容的访问权的用户可以简单地停止“提供”该内容,或者换句话说,停止发布相应的提供者记录。但是,这并不意味着内容会从网络中消失,因为已检索到该内容的其他对等方可能仍将其保留在其缓存中并提供它。

  另外,协议实验室提供的IPFS网关具有CID拒绝列表。为了保护内容,此列表中的CID被双重哈希处理,并且IPFS网关在提供内容之前检查是否已拒绝/阻止该内容。


  :是否可以检查特定的CID是否已删除(即添加到拒绝列表)?

  答:要检查CID是否在给定网关的拒绝列表中,您可以尝试在网关上解析该CID并获取HTTP响应代码,该代码将通知您是否已拒绝它。每个拒绝列表都由运营组织单独维护-整个IPFS网络没有全局拒绝列表。


  拒绝者似乎并不属于分散式基础架构。

  答:任何个人或组织都可以运行公共IPFS网关并运行自己的拒绝列表。从这个意义上讲,拒绝列表的(内容)不是由集中式实体决定的。


  :网关是否经过身份验证?

  答:否。任何节点都可以运行网关。它们未经身份验证。网关没有内置的信誉层。许多组织,包括协议实验室,Cloudflare,Infura和其他组织,都在运行IPFS网关-您可以在此处查看已知公共网关的列表。如果特定网关决定流氓,但未提供正确的路由信息,则应切换到其他网关提供商。


  :IPNS记录保存在哪里?

  答:IPNS使用与内容路由相同的基础架构,即DHT。对等方的公钥的多哈希值在DHT上注册,以指向可变内容。还有其他分配IPNS记录的方法:为此目的,使用了称为gossipsub的pubsub协议(spec,techrep,最近的演讲),作为分配IPNS记录的较快方法。如前所述,PubSub与DHT上IPNS的区别在于推(PubSub)与拉(DHT)模型。


  :如果将名称放入DHT中,并且名称可以指向可以由不同人员(好的,坏的)更改的不同事物,那么这会是一个很大的安全问题吗?

  答:IPFS使用的是受自认证文件系统(SFS)启发的技术,并将公钥的CID放入DHT。每次发布者发布内容的新版本时,都必须使用其私钥对记录进行签名,因此,只有原始作者才能以该身份发布。我们将此系统称为IPNS,用于行星际名称系统


  :其他节点如何知道它们具有名称的正确密钥?

  答:当节点在DHT上查找IPNS名称时,它会从DHT指定的所有对等方检索记录以存储数据。由于记录具有序列号,因此客户端可以轻松确定与IPNS密钥相对应的最新值。还有一个DHT查找快捷方式,用户无需等待查找完成就可以决定等待接收记录的定额Q(当前设置为Q = 16),然后再确定它有足够的信息来确定记录的数量。最近的记录。


  :如果存储IPNS记录的节点脱机,则IPNS记录会丢失,并且如果有人未在24小时内对其进行更新,则无法提供该记录。

  答:这是正确的,IPFS记录的发布者(即不变的CID)也是如此。可能发生以下两种情况之一:

  如果内容已被请求并且已由其他某个节点检索和缓存,则可以由缓存节点为其提供服务。

  如果已检索(和缓存)该内容的一个(或某些)对等方决定继续保存/提供该内容,则可以“固定”它,这意味着它们已成为该内容的永久提供者。


  :缓存内容时,系统如何得知缓存的内容以及如何使用/解析该内容?

  答:缓存内容的对等方还将提供者记录发布到DHT,以声明它们也是其缓存中所有内容项的提供者。


  :缓存的内容是否与内容的原始副本相同?

  答:可以解析并提供缓存的内容,直到下一个“垃圾回收”期间为止,在该时间点之前,缓存的内容将过期,除非将其“固定”(因此,将永久复制,直到用户说不出来)。请注意,在撰写本文时,默认情况下,垃圾收集处于关闭状态。


  问:保持重新发布IPNS记录的需求需要更多的开销-发布者需要保持在线状态,而ISP需要提供连接性。与其他系统相比如何?

  答:数据主机需要保持在线状态才能保持其内容的可访问性。在IPFS中,数据与提供程序无关,任何人都可以重新托管数据。用户可以依靠某些服务(称为固定服务)在脱机时保持内容在网络上的可用性。

  在IPNS中,默认配置要求内容发布者(或具有发布者私钥访问权限的委托人)能够重新发布签名的更新,以使其IPNS记录保持有效。虽然当原始发布者下线时第三方目前可以使IPNS记录保持活动状态,但是在现有实现中默认进行此项工作仍需要一些工作。


  问:IPFS依赖于DNS,因此IPFS始终只能是覆盖。IPFS可以在链路层上路由吗?

  答:IPFS不依赖DNS。相反,我们支持扩展名DNSLlink,它是IPFS协议之外的一种机制,IPFS实现可以使用该机制来注册人类可读的名称并将其链接到CID,IPNS甚至其他DNSLinks。DNSLink确实依赖DNS,但它是可选的,用户可以自由使用ENS或Unstoppable Domains等分散域名。

  关于在链路层上进行路由,IPFS当前不利用链路层上的路由来优化其数据传输,但是将来确实有计划这样做。


  问:对等方是否需要进行任何基础设施更改以增强网络性能?

  答:IPFS的设计目的是不依赖ISP的基础架构升级才能运行。但是,这并不意味着它不能使用网络内实体的增强功能,例如网络内缓存。


  问:您必须确切知道要查找的内容。DHT很好,但是很难知道其中有什么。CID和真实身份之间的绑定在哪里进行?

  答:IPFS是一种分布式文件系统,用于在面向最终用户的内容发现(例如,当前如何使用HTTP寻址/托管Google搜索服务的站点)下方的一层上为应用程序提供动力。IPFS管理为特定CID提供,存储和获取内容;其余的(将用户连接到与该应用程序相关的CID或首先找到该应用程序)必须发生在IPFS本身之上的一层。


  问:在DHT中,您是根据覆盖层进行布线的。没有附近的概念。

  答:是的,这是正确的,这是大多数DHT实施的已知缺点。这些团队目前正在研究和评估其他DHT结构,例如Coral和Canon DHT,以及非DHT路由和分辨率组件,以便将感兴趣的本地概念整合到内容分辨率中。但是,这仍在进行中,尚未集成到生产系统中。


  :pubsub如何工作?它基于CID吗?主题由CID代表吗?您如何表达主题?

  答:不,主题不能用CID表示(尽管可以)。当前使用的pubsub协议(称为gossipsub)是基于主题的pubsub系统,而不是基于内容的系统。


  :在谈话开始时,您提到目的是从网络(即外部实体)中删除信任。你能详细说明吗?您如何相信某个内容将通过某个密钥发布?

  答:通过自己的哈希命名内容并将其发布在分布式P2P网络中,从本质上克服了与将信任放入外部实体(例如内容托管和内容解析实体)相关的若干问题。内容可以自我验证,因此可以在本地验证。只要内容由发布者的私钥签名,内容消费者就可以在不依赖外部实体的情况下验证内容的真实性。


  :我可以重新发布cnn.com/news吗?

  答:Google提出了“签名HTTP交换”(或SXG)的概念。根据SXG的说法,HTTP“交换”或请求/响应事务本身是经过加密签名的。反过来,这意味着浏览器既可以验证内容的来源(因为它是由原始提供者签名的),也可以验证内容本身的完整性。通过这种巧妙的技术,可以从任何地方访问HTTP内容(不包括Cookie和其他不可缓存的内容),包括分散式系统(如IPFS),同时仍可以验证内容是否来自正确的发布者。

  为了实现签名HTTP交换,将签名添加到原始HTTP内容中,以包括:i)原始HTTP内容,ii)证书URL,iii)到期日期(设置为约7天的低值) ,以及iv)有效负载的摘要。


最新推荐