NIX×IPFS-里程碑1

黑曜石系统公司正在向NIX添加对IPFS的支持，这样构建的产品就可以持久化到IPFS中并从IPFS中获取。这增加了弹性，使NIX用户更容易复制和分发他们的工作-通过使用IPFS内容地址(CID)对等地缓存和分发源代码(希望在未来的中间构建步骤中也是如此)。

NIX通常用作包管理器，但其核心是一个通用的构建工具，如make、Ninja或Bazel。

NIX的不同之处在于它专注于沙箱构建步骤和缓存构建构件。有了这些功能，计划和构建构件都不会有隐藏的依赖关系，因此构建可以重新生成并健壮地构建共享构件。

这使得Nix成为与IPFS这样的对等系统配合使用的理想构建工具。实际上，使用Nix的首要项目是Nixpkgs，这是一个软件包集合(带有相关的Linux发行版)，是GitHub上最大、贡献最广泛的项目之一。

黑曜石系统是一家端到端的软件产品咨询公司，为从最近投资的初创公司到大型机构的每个人提供服务。自2014年成立以来，我们一直将NIX作为我们生产部署和开发工作流程中不可或缺的一部分。

对于我们来说，NIX是一个不可或缺的工具，因为我们经常需要在项目之间切换，而NIX使每个项目开发环境的设置和共享变得微不足道，也使得最终用户在自己的机器上安装的软件(如区块链钱包)的打包变得容易。

虽然NIX构建计划是可重现的，但仍然存在一个限制，那就是初始数据源代码的可用性。NIX计划有所谓的“固定输出派生”。这些是非沙箱构建步骤，可以通过网络访问下载各种源代码。它们产生的数据必须与预先固定的散列匹配，因此不能利用沙箱来导致不确定的输出。

这样做的最大问题是，如果URL变得不可访问或下载的数据是不确定的(例如，由于某些元数据)，这个构建步骤将失败-换句话说，我们面临的问题与IPFS试图用一般Web解决的链接完全相同！IPFS解决方案是正确的-我们不应该依赖于一些源代码最初上传的位置。而且我们已经通过内容地址识别源代码，所以IPFS解决方案甚至不是我们现有工具和社区实践的巨大飞跃。

是的，我们已经可以固定和缓存那些固定输出的构建步骤的结果，就像我们使用常规构建步骤一样，但是我们完全独立于上游提供的服务来固定和缓存我们自己的源代码缓存。对于NIX的用户来说，每个人维护他们自己的不合作的源代码缓存是乏味而低效的，对于下游用户来说更是如此，他们必须单独手动配置每个缓存，而他们所需要的只是一些由于内容地址的原因而可以自我验证的源代码。

对于整个NIX社区来说，我们终于有机会利用我们在可重现性方面的辛勤工作并使其成为现实，而不是依赖我们的集中式cache.nixos.org在源代码腐烂之前构建工件，而是每个人都可以自由地使用Nixpkgs作为源代码或二进制发行版-这是最初的目的。

特别是对于黑曜石开源软件的用户来说，他们终于有了一种简单而健壮的方式，既不信任我们自己的预先构建的二进制文件，也不信任cache.nixos.org的，而是从源代码构建一切，这使得审计安全关键代码变得更容易。

理想情况下，我们希望与上游开发人员自己和其他下游发行版协作缓存和分发源代码。与我们见过的任何其他模式相比，IPLD更了解使用原始的“原生”引用来寻址数据的价值，而不是其他人无法理解的定制的第三方格式。

我们认为这是实现这种合作的关键。上游DEV可以简单地继续使用GIT Repos(或IPLD支持的任何其他带有内容寻址的版本控制系统)。下游发行版直接消费数据，不需要任何模糊数据真实性的转换步骤。任何一方都不需要做另一方曾经处理的琐事。

我们希望NIX能够将IPF用作当今存在的其他类型的替代者之外的“替代者”或源/构建构件的提供者。

作为这项工作的一部分，我们教授了Nix Git树散列，这样它就可以以IPF能够理解的方式处理GIT报告的内容，从而帮助IPF、NIX、上游合作者和其他对存档和传播源代码感兴趣的各方找到引用这些工件的通用方法。虽然GIT散列方案有其局限性，但我们认为它是GIT数据多方协作的最佳方法。

展望将IPF用于构建产品和部署，我们还为IPF和NIX添加了对围绕GIT树哈希的元数据格式的支持，以便在单独安装的文件系统树之间传送具有运行时依赖关系的数据。最后，我们提供了一种将现有的NIX构建构件转换为这种新数据格式的方法。

NIX实际上并不对常规构建步骤产生的数据进行内容寻址(与上面描述的“固定输出”构建步骤相反)，而是基于创建它们的计划来寻址它们。

存在计划改变而结果不变的情况--比如当有人编辑评论时。除了造成下游的额外重建之外，这还混淆了原始数据与其出处之间的分离。在点对点系统中，谁提供数据并不重要(我们希望利用这一点并不重要)，但谁声称数据代表了什么是绝对重要的。

有了这一核心改进，我们可以在IPLD中创建新的改进版本的构建计划，并直接从每个构建步骤生成新支持的IPFS兼容格式，不需要从遗留的输入寻址数据进行手动转换。这最后一步将两个里程碑的所有内容结合在一起。

我们很高兴地宣布里程碑1完成了！作为对社区反馈的响应，在迁移到理想的git树哈希之前，我们还能够做一些额外的工作，让NIX社区开始使用IPF。

这为我们的里程碑2中的一些目标奠定了基础，我们希望这一步可以帮助每个人过渡到更优雅地使用IPF。

最后，我们最近在Nix星期五节目流上做了一次采访，回顾了我们所有的工作，还更广泛地讨论了我们如何看待IPFS和NIX生态系统的结合。你可以在这里观看录音：

我们已经开始实现里程碑2，包括改进的生成内容寻址数据的构建步骤。我们预计这将是大部分工作，最终的IPFS集成将相对顺利，因为到那时，NIX和IPF的概念将非常一致！

我们一直在小心翼翼地处理多个分支，将特性工作与内部的一般改进分开，因此我们已经能够将其中的许多改进放在上游。

我们喜欢这种方法，因为它允许我们不断地与社区接触，并为功能本身留下更多可读性的差异。

我们希望您能让演示旋转，并喜欢您看到的内容。请继续关注里程碑2！