江苏龙网

  1. 首页 > 人文 > >

技术编程|IPFS应用进展：Nix使用IPFS进行内容分发


黑曜石系统（Obsidian Systems）向Nix添加了对IPFS的支持 ， 以便可以将构建产品持久保存到IPFS或从IPFS中提取 。 这增加了弹性 ， 并使Nix用户更容易复制和分发他们的工作-通过使用IPFS内容地址（CID）对等地缓存和分发源代码（并希望在将来的中间构建步骤中） 。
什么是Nix？
Nix通常用作包管理器 ， 但其核心是通用的构建工具 ， 例如Make ， Ninja或Bazel 。
Nix的与众不同之处在于 ， 它专注于沙盒构建步骤和缓存构建工件 。 使用这些功能 ， 计划和构建工件都不会具有隐藏的依赖性 ， 因此可以复制构建并可靠地共享构建工件 。
【技术编程|IPFS应用进展：Nix使用IPFS进行内容分发】这使Nix成为与IPFS等对等系统一起使用的理想构建工具 。 确实 ， 使用Nix的首要项目是Nixpkgs ， 这是一个软件包集合（带有相关的Linux发行版） ， 是GitHub上最广泛的最大项目之一 。
为什么我们使用Nix？
黑曜石系统（Obsidian Systems）是一家端到端软件产品咨询公司 ， 为从新近投资的初创公司到大型机构的所有人提供服务 。 自2014年成立以来 ， 我们已将Nix纳入生产部署和开发人员工作流程的组成部分 。
Nix对我们来说是必不可少的工具 ， 因为我们经常需要在项目之间进行切换 ， 并且Nix使得建立和共享每个项目的开发环境变得微不足道 。 它还使打包最终用户在自己的计算机上安装的软件变得容易 ， 例如区块链钱包 。
激发我们使用IPFS的挑战
尽管Nix构建计划是可复制的 ， 但仍然存在一个局限性 ， 那就是初始数据（源代码）的可用性 。 Nix计划具有所谓的“固定输出派生” 。 这些是未沙盒化的构建步骤 ， 可以通过网络访问下载各种资源 。 它们产生的数据必须与固定的哈希值匹配 ， 因此无法利用沙箱的不足来导致不确定的输出 。
这样做的最大问题是 ， 如果URL不可访问或下载的数据不确定（例如由于某些元数据） ， 则此构建步骤将失败-换句话说 ， 我们正面临着与linkrot IPFS完全相同的问题用网络一般解决！
IPFS解决方案是正确的-我们不应该依赖最初上传某些源代码的位置 。 而且我们已经在通过内容地址标识源代码 ， 因此IPFS解决方案与我们现有的工具和社区实践相比 ， 还算不上什么大的飞跃 。
是的 ， 我们已经可以像固定常规构建步骤一样固定和缓存这些固定输出的构建步骤的结果 ， 但是我们仍然完全独立于上游提供的内容而对自己的源代码进行缓存 。 Nix用户各自维护自己的不合作的源代码缓存是乏味且效率低下的 ， 对于下游用户而言 ， 当他们想要的只是一些源代码时 ， 他们将不得不分别手动配置每个缓存 ， 这更加繁琐且效率低下 。 由于内容地址而进行自我认证 。
值
对于整个Nix社区 ， 我们终于有机会利用我们在可复制性方面的辛勤工作 ， 并将其变为现实 。 每个人都应该随意使用Nixpkgs作为源或二进制发行版 ， 而不是像最初打算的那样依靠我们集中的cache.nixos.org来构建工件 。
特别是对于Obsidian开源软件的用户 ， 他们终于有了一种简单而强大的方法来信任我们自己的预构建二进制文件或cache.nixos.org ， 而不必从源代码构建所有内容 ， 这使审核安全关键代码更加容易 。
理想情况下 ， 我们希望与上游开发人员本身和其他下游发行版协作来缓存和分发源代码 。 IPLD比我们已经看到的任何其他模式都更了解使用其原始预期的“本机”引用来寻址数据的价值 ， 而不是别人无法理解的某些定制的第三方格式 。
我们认为这是实现这种合作的关键 。 上游开发人员可以继续使用git repos（或任何其他具有IPLD支持的内容寻址功能的版本控制系统）进行工作 。 下游发行版直接使用该数据 ， 而无需执行任何转换步骤来掩盖数据的真实性 。 任何一方都没有面临另一方过去处理的杂务 。
使用范围
我们旨在分两个阶段解决这些问题 。
里程碑1：使用IPFS分发
我们希望Nix能够将IPFS用作当今存在的其他替代品的“替代者”或源/构建工件的提供者 。
在此过程中 ， 我们教了Nix git树哈希 ， 以便它可以IPFS理解的方式对git repos进行内容寻址-帮助IPFS ， Nix ， 上游合作者和其他对归档和传播源代码感兴趣的各方找到一个引用这些工件的常用方法 。 尽管git哈希方案有其局限性 ， 但我们认为这是在git数据上进行多方协作的最佳方法 。
展望将IPFS用于构建产品和部署时 ， 我们还为IPFS和Nix的git树哈希添加了对元数据格式的支持 ， 以在单独安装的文件系统树之间传递具有运行时相关性的数据 。 最后 ， 我们提供了一种将现有Nix构建工件转换为这种新数据格式的方法 。
里程碑2：使用IPFS进行构建
Nix实际上并没有对常规构建步骤（与上述“固定输出”构建步骤相反）生成的数据进行内容寻址 。 相反 ， 它基于制定它们的计划来解决它们 。
存在这样的情况-例如当有人编辑评论时-计划会更改 ， 但结果不会更改 。 除了在下游造成额外的重建之外 ， 这还会混淆原始数据与其来源之间的分隔 。 在点对点系统中 ， 谁提供数据并不重要（我们想利用这一点无关紧要） ， 但是谁声明数据代表什么绝对重要 。
借助这一核心改进 ， 我们可以在IPLD中改进构建计划的新版本 ， 并直接从每个构建步骤中生成新支持的与IPFS兼容的格式 ， 而无需从旧的输入寻址数据进行手动转换 。 最后一步将两个里程碑中的所有内容融合在一起 。
有关完整的细分 ， 请访问我们的公开赠款提案 。
项目进展
我们很高兴宣布里程碑1完成！为了回应社区的反馈 ， 我们还能够做一些额外的工作 ， 以使Nix社区在迁移到理想的git树哈希之前开始使用IPFS 。
这为我们里程碑2的某些目标打下了基础 。 我们希望这一步骤可以帮助每个人更平稳地过渡到使用IPFS 。
开始使用我们的指南存储库 ， 尤其是我们的教程 。
最后 ， 我们最近对Nix Friday流进行了一次采访 ， 讨论了我们的所有工作 ， 并且还更广泛地讨论了我们如何看待IPFS和Nix生态系统的融合 。

技术编程|IPFS应用进展：Nix使用IPFS进行内容分发
本文插图

下一步是什么？
我们已经开始实施里程碑2 ， 包括改进的生成内容寻址数据的构建步骤 。 我们希望这是大部分工作 ， 最终的IPFS集成会相对顺利 ， 因为到那时 ， Nix和IPFS的概念将变得如此整齐！
我们一直在努力处理许多分支 ， 以将要素工作与内部的总体改进区分开来 ， 因此能够将许多此类改进纳入上游 。
我们喜欢这种方法 ， 因为它使我们能够不断与社区互动 ， 并为功能本身留下了更具可读性的差异 。
我们希望您可以演示一下 ， 并喜欢您看到的内容 。 请继续关注里程碑2！


    推荐阅读


    上一篇：记者|澳大利亚情报机构突击搜查中国记者 中国记协回应

    下一篇：侦察|美国军机再挂马来西亚电码，抵近侦察广东