高纬度描述IPFS？这段访谈道出了关键

近期，ResNetLab受邀向Named Date Networking（命名数据网络联盟）展示了“IPFS体系结构的高级概述”！

ResNetLab的起源来自IPFS和libp2p项目发展的现实需求，目的以增强这两个项目的研究能力，并应对其将网络扩展到全球规模和更远的星际之间的严峻挑战。

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

IPFS用应用程序层的方法，达到内容可寻址的愿景。以下是在演示过程的谈话中，从IPFS体系结构角度的提问与解答。文中提及的永久Web、验证密钥、创建梅克尔树等最新干货，墙裂建议码住，以备查看！

Q1.基本单位的内容块大小是多少？用户可以使用不同的块大小吗？

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

Q2.Merkle-Tree是如何创建的？

答：Merkle-DAG结构（称为星际链接数据或IPLD）是在用户将文件添加到其本地IPFS节点时在本地创建的。在IPFS网络中发布文件时，该文件不会在其他节点中复制，目的是避免在未经同级同意的情况下，将内容添加到同级本地存储。取而代之的是，该文件最初由对等方分发，并根据请求将其发布到网络。

然后，原始提供者检索文件的任何节点也可以充当文件的提供者，从而为内容创建缓存网络。当将文件发布到网络时，“提供者记录”会放在DHT（分布式哈希表）中以指向本地节点进行检索。如果网络中的其他对等方希望成为文件的永久提供者，则也可以“固定”文件。如果他们没有固定文件，那么文件最终将被作为“垃圾收集”。

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

答：IPFS体系结构中没有任何机制可以跟踪发布到网络的文件，让全世界知道新添加的内容/CID必须在“带外”发生。迄今为止，尚无成果。该话题，协议实验室和整个社区都非常感兴趣。

星际命名系统（IPNS）及其支持的PubSub协议，是传播有关新发布内容的信息的另一种方法。应用程序可以利用此选项在应用程序本身的领域内传播（即推送）有关新发布内容的信息。当IPNS在DHT之上运行时，它也可以基于拉的方式工作。

Q4.我是否需要具有梅克尔树的整个结构才能检索其中的一部分？如果我只想检索文件的一部分，则根CID似乎还不够。

答：用户不需要具有Merkle-DAG的整个结构即可检索其中的一部分。为了仅检索Merkle-DAG的一部分（由一个或多个块CID组成），用户需要具有这些特定的CID。另外，您可以使用根CID和路径符号来访问Merkle-DAG中的文件。

Q5.一旦为文件块分配了CID，该块是否不变？

答：是的，一旦计算出块/块的CID，它将永远保持不变，这是“永久Web”的概念，这是存储和交付系统的重要属性。当然，该块本身可以对其进行更改。但是新文件的CID将与旧文件不匹配，因此必须单独添加新版本（除非内容是通过IPNS在公共密钥下发布的）。

Q6.如何从IPFS网络撤消CID？

答：这样的CID是永久性的，不能被“撤消”，因为它是特定内容的哈希值。不再希望提供对某些内容的访问权的用户，可以简单地停止“提供”该内容。

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

Q7.拒绝者似乎并不属于去中心化基础架构。

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

Q8.网关是否经过身份验证？

答：否。任何节点都可以运行网关。他们未经身份验证。网关没有内置的信誉层。许多组织，包括协议实验室、Cloudflare、Infura和其他组织，都在运行IPFS网关。

Q9.IPNS记录保存在哪里？

答：IPNS使用与内容路由相同的基础架构，即DHT（分布式哈希表）。对等方的公钥多哈希值在DHT上注册，以指向可变内容。还有其他分发IPNS记录的方法：使用称为gossipsub的pubsub协议，作为分发IPNS记录的较快方法。

Q10.如果将名称放入DHT（分布式哈希表）中，并且名称可以指向可以由不同人员更改的不同事物，那么这可能是一个很大的安全问题吗？

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

Q11.其他节点如何知道它们具有名称的正确密钥？

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

Q12.缓存内容时，系统如何得知缓存的内容以及如何使用/解析该内容？

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

Q13.IPFS依赖于DNS，因此IPFS始终只能是覆盖。IPFS可以在链路层上路由吗？

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

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

Q14.对等方是否需要进行基础设施更改以增强网络性能？

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

Q15.您必须确切地知道要寻找什么。DHT很好，但是很难知道其中有什么。CID和真实身份之间的绑定在哪里进行？

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

Q16.在DHT中，您是根据叠加层进行布线的，没有附近的概念。

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

Q17.pubsub如何工作？它基于CID吗？主题由CID代表吗？您如何表达主题？

答：不，主题不能用CID表示。当前使用的pubsub协议，称为gossipsub，是基于主题的pubsub系统，而不是基于内容的pubsub系统。

Q18.您提到目的是要从网络（即外部实体）中删除信任。您如何相信某个内容将通过某个密钥发布？

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

—-

编译者/作者：引擎矿机

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。