为什么我们需要多种格式?
好吧,我认为我们需要它。但是,这是什么?
如何使用它?
计算中的每个选择都有一个权衡。这包括格式,算法,编码等。即使有大量的计划,决策也可能导致沿途打破变更,或者导致不再最佳的解决方案。在不引入重大变化的情况下允许系统发展和壮大非常重要。
但是,为什么我们需要多种格式?
为了了解对Multiformats的需求,让我们以git 协议为例。很多人每天使用它来使用Github,Gitlab,Bitbucket等服务。我们知道git在很多事情上都使用了哈希。现在,git使用SHA-1作为其哈希算法。
这些哈希算法起着非常重要的作用。他们确保事情安全。不仅在git中,而且在医疗保健,全球金融系统和政府中也是如此。
散列函数如何工作?
它们的工作方式是单向功能。因此,您可以使用散列函数从输入(某物)获取输出(散列),但是实际上从输出中获取输入是不可能的。
但是随着时间的流逝,随着功能越来越强大的计算机的发展,其中一些哈希函数开始失效。这意味着您现在可以从输出中获取输入,从而破坏了使用该功能的系统的安全性。这就是MD5哈希函数发生的情况。
因此,就像MD5一样,有一天SHA1将被破坏……然后我们将需要使用更好的哈希函数。但是这里的问题在于,由于这些算法与生态系统紧密相连,因此很难进行此类更改。加上使用旧SHA1的所有代码库会发生什么?所有这些都将变得不兼容……太烂了!
而且,这种非面向未来和不兼容的问题不仅限于哈希算法。网络协议也是这些问题的主要宿主。
以2015年推出的HTTP / 2为例。从网络的角度来看,HTTP / 2进行了一些显着的更改。由于它是二进制协议,因此任何假定其为HTTP / 1.1的设备都将崩溃。这意味着要更改所有使用HTTP / 1.1的内容,包括浏览器和Web服务器。
因此,总结起来,我们面临许多问题:
引入重大更改以更新具有更高安全性的系统。
由于一些不可预见的问题而引入重大更改。
有时我们需要权衡多个选项,每个选项都具有所需的特征,但您只能拥有一个。曾经去过一家糖果店,想在那里买整个商店。但是妈妈让你只买一个。。。是的,技术也一样。
这些问题不仅破坏了事情,而且使整个开发周期变慢,因为仔细转移整个系统需要花费大量时间。我们今天所看到的几乎每个系统都从来没有考虑到某天它会过时的事实而设计。
这不是我们希望未来的方式。因此,我们需要接受事实的改变。Multiformats项目引入了一套包含这一事实的标准/协议,并允许多种协议共存,因此即使发生重大变化,生态系统仍支持该协议的所有版本。现在,我们知道“为什么”,让我们看看“什么”……
如今,Multiformats Project是针对未来系统的协议的集合。他们主要通过使用自我描述来增强格式值来实现此目的。这样可以实现互操作性,协议敏捷性,并帮助我们避免锁定。
协议的自描述方面有一些规定:
它们必须在带内(带有值);不带外(在上下文中)。
他们必须避免锁定并提高可扩展性。
它们必须紧凑并且具有二进制打包的表示形式。
它们必须具有人类可读的表示形式。
1)多格式协议
当前,我们具有以下多格式协议:
多哈希:自描述哈希
Multiaddr:自描述网络地址
Multibase:自我描述的基本编码
多编解码器:自描述序列化
多流:自描述流网络协议
多流选择:友好的协议多路复用。
Multigram(WIP):自描述的分组网络协议
Multikey:加密密钥和伪像
每个项目都有其使用各种语言的实现列表。好。这听起来有点复杂。让我们分解一下,我们将研究所有这些多格式协议,并尝试了解它们如何工作。
Multihash是一种协议,用于区分各种公认的哈希函数的输出,地址大小和编码注意事项。编写应用程序以防将来使用哈希并允许多个哈希函数共存是很有用的。
1)更安全,更轻松的加密哈希功能升级
在依赖于密码安全哈希函数的系统中,多重哈希特别重要。攻击可能会破坏安全哈希函数的加密属性。这些密码破解在大型工具生态系统中尤其令人痛苦,在大型生态系统中,工具可能已对哈希值(例如函数和摘要大小)进行了假设。像所有做出这些假设的工具一样,必须升级以使用新的哈希函数和新的哈希摘要长度,升级已成为噩梦。工具可能会遇到严重的互操作性问题或易于出错的特殊外壳。正如我们前面讨论的,git示例中可能存在许多问题:
有多少程序假设git哈希是sha1哈希?
Multihash是一种协议,用于区分各种公认的哈希函数的输出,地址大小和编码注意事项。编写应用程序以防将来使用哈希并允许多个哈希函数共存是很有用的。
1)更安全,更轻松的加密哈希功能升级
在依赖于密码安全哈希函数的系统中,多重哈希特别重要。攻击可能会破坏安全哈希函数的加密属性。这些密码破解在大型工具生态系统中尤其令人痛苦,在大型生态系统中,工具可能已对哈希值(例如函数和摘要大小)进行了假设。像所有做出这些假设的工具一样,必须升级以使用新的哈希函数和新的哈希摘要长度,升级已成为噩梦。工具可能会遇到严重的互操作性问题或易于出错的特殊外壳。正如我们前面讨论的,git示例中可能存在许多问题:
有多少程序假设git哈希是sha1哈希?
Multihash是一种协议,用于区分各种公认的哈希函数的输出,地址大小和编码注意事项。编写应用程序以防将来使用哈希并允许多个哈希函数共存是很有用的。
1)更安全,更轻松的加密哈希功能升级
在依赖于密码安全哈希函数的系统中,多重哈希特别重要。攻击可能会破坏安全哈希函数的加密属性。这些密码破解在大型工具生态系统中尤其令人痛苦,在大型生态系统中,工具可能已对哈希值(例如函数和摘要大小)进行了假设。像所有做出这些假设的工具一样,必须升级以使用新的哈希函数和新的哈希摘要长度,升级已成为噩梦。工具可能会遇到严重的互操作性问题或易于出错的特殊外壳。正如我们前面讨论的,git示例中可能存在许多问题:
有多少程序假设git哈希是sha1哈希?
有多少脚本假定哈希值摘要恰好是 160位?
这些值更改时将破坏多少个工具?
当这些值更改时,有多少程序将无提示地失败?
这正是Multihash闪耀的地方。它是专为升级而设计的。
使用Multihash时,系统会警告使用者其哈希值,以防在中断时可能必须升级这些哈希值。即使系统一次可能仍然只使用一个哈希函数,使用多哈希也使应用程序清楚地知道哈希值可能会使用不同的哈希函数,或者将来会更长。工具,应用程序和脚本可以避免对长度进行假设,而应从multihash值中读取它。这样,绝大多数工具(可能不会进行任何哈希检查)将根本不需要升级。这极大地简化了升级过程,避免了数百或数千个软件工程时间的浪费,深深的挫败感和高血压。
2)多哈希格式
多重哈希遵循TLV(type-length-value)模式。
该类型
该长度
该值
多哈希正则表达式
多哈希示例
为了了解多哈希格式的重要性,让我们使用一些视觉辅助。
3)考虑相同输入的这4个不同的哈希
4)相同长度:256位
5)理念:自我描述以区别价值观
6)Multihash:fn代码+长度前缀
7)Multihash:一种相当不错的多格式
Multiaddr是一种用于编码来自各种公认的网络协议的地址的格式。编写应用程序以确保将来的地址使用是可行的,并允许多个传输协议和地址共存。
1)网络协议骨化
Internet中当前的网络寻址方案不是自描述的。以下形式的地址在很大程度上取决于解释和边带环境。他们做出的假设使应用程序也做出了这些假设,这导致了很多“此类地址”特定的代码。网络地址及其协议会生锈,并且以后的协议也无法取代它们,因为该地址可以防止更改。
例如,考虑:
2)多地址格式
multiaddr值是一种递归 (TLV)+(类型-长度-值重复)编码。它有两种形式:
一个人类可读版本打印到用户时使用的(UTF-8)
一个二进制包装版本以存储被使用,传输线路上,并且如在其它格式原语。
可读版本
路径符号嵌套协议和地址,例如:/ip4/127.0.0.1/udp/4023/quic(这是重复的部分)。
协议只能是代码,也可以具有地址值(位于下方/)(例如/quic and /ip4/127.0.0.1)
该类型
该值
令人敬畏的IPFS是一个社区维护和更新的项目,工具列表,或几乎任何与IPFS相关的东西,非常棒。要查看更多信息,或将您的信息添加到列表中,请访问GitHub上的Awesome IP
Multiaddr可读正则表达式
3)二进制打包版本
该类型
的长度是一个整数无符号变量计数地址值的长度,以字节为单位。
具有确切地址值大小或没有地址值的协议将省略该长度。
该值
该值是通过谁没有地址值的协议省略。
FS。
MultiAddr二进制正则表达式
1)动机
多编解码器是自描述的协议/编码流。(请注意,文件是流)。它旨在解决长期存在的问题:
我有一个位串,数据使用什么编解码器编码?
不用争论哪个数据序列化库是最好的,而是让我们现在选择最简单的库,并将可升级性构建到系统中。选择永远不会永远。最终,所有系统都被更改。因此,拥抱现实,立即在您的系统中构建变化。
Multicodec使您摆脱了过去错误的专横。与其尝试事先解决所有问题,要么继续使用我们都同意不再适合的方法,为什么不让系统随着今天而不是昨天的用例而发展和发展。要解码传入的数据流,程序必须事先知道数据的格式,或从数据本身学习格式。
(1)排除了可能会提供多种格式之一的运行协议,而无需事先达成协议。多流使用自我描述使(2)变得整洁。而且,这种自我描述允许协议的直接分层,而不必在父(或封装)协议中实现支持。
2)协议如何工作?
multistream是一种自我描述的多格式,它以其他一些自我描述来包装其他格式:
请注意,在ASCII版本上,开头的varint未被表示,您应该考虑到这一点。
3)协议路径
multistream允许我们在通用名称空间中指定不同的协议,从而能够轻松识别,复用和嵌入它们。我们使用a path而不是an 的概念,id因为它意味着是Unix友好的URI。
好的路径名应该是可以理解的-这意味着,如果某些机器或开发人员(对您的协议一无所知)遇到路径字符串,他们应该能够查找并确定如何使用它。
一个好的路径名的示例是:
/ipfs/Qmaa4Rw81a3a1VEx4LxB7HADUAXvZFhCoRdBzsMZyZmqHD/ipfs.protocol/http/w3id.org/ipfs/1.1.0
一个很好的路径名的示例是:
/ipfs/Qmaa4Rw81a3a1VEx4LxB7HADUAXvZFhCoRdBzsMZyZmqHD/ipfs.protocol/http/w3id.org/ipfs/1.1.0
这些路径名称恰好是可解析的-不仅在“多流复用器(例如multistream-select)”中,而且在整个Internet上(只要程序(或OS)知道如何使用/ipfs和/http协议)。
现在,让我们回答一些问题以了解其重要性。
4)为什么选择多码流?
如今,人们会说多种语言,并使用常见的语言作为界面。但是每种“通用语言”都随着时间的流逝而发展,甚至发生了根本性的变化。为什么我们期望程序会有所不同?
事实是事实并非如此。程序使用各种编码。今天,我们喜欢JSON。昨天,XML风行一时。XDR解决了所有问题,但有点复古。Protobuf对于学校来说仍然太酷了。
程序很难。您不能一直将JSON传递到protobuf解码器中并希望它们对齐。因此,我们必须帮助他们。这就是multicodec的目的。
对于我的用例而言,完整路径太大,有没有更小的路径?
是的,请检查multicodec。它使用varint和表来实现同一目的。
Multigram对数据报进行操作,这些数据报可以是UDP数据包,以太网帧等,并且不可靠且无序。它所做的只是在数据包的前面添加一个字段,该字段表示此数据包的协议。然后,连接的端点可以为每个协议使用不同的数据包处理程序。
由于Multigram是WIP,因此我不会对其进行深入介绍。但是您想跟踪它的发展,可以在这里访问。
好了,现在我们已经涵盖了“ What”,让我们一起玩一下以了解其功能
1)让我们玩多种格式
在这里,我们将使用Multihash,Multiaddr和Multicodec。您还可以在这里找到本教程的完整代码。我们将在本教程中使用JS实现。
2)项目设置
创建一个名为的文件夹multiformats_tut。现在,进入文件夹。
3)安装
确保已安装npm并nodejs在系统上。
4)运行此命令。
node multibase_tut.js
翻译编辑:星际大陆