1. IPFS点滴资讯首页
  2. 实战操作

整天玩IPFS

这几乎是一个有争议的分散式网络技术研究故事,但在开始之前,有一些事情我想确保你们所有人,我亲爱的读者都知道。

第一个是在第一个疯狂科学周末期间的最初目的:我想围绕分散网络时的一些主要流行词进行一些研究,重点关注着名的点对点协议:IPFS ,制作简单的例子键通(PoC小号,这样,如果它适合于使用在一个我们可以评估Beakyn的,为了找到一个更应用高效廉价可靠的方式来服务于我们的数据。

其次,我有一个免责声明:这篇文章有时听起来比实际上更具技术性,所以如果你有任何问题或其他反馈,你不要害怕任何流行语和ping我 – 如Juan通常说:

“嘿笨!你可以做到这一点或那样“。

研究组织

这项研究的最终结果分为三个不同部分:

  • 研究综合↝猜猜是什么?你现在正在阅读的帖子🙈。
  • 示例发布脚本↝这是一个简单的Node.js脚本,它基本上提取我们的最后  .pbf 文件,加密它们,然后将数据发布到IPFS。它还包含一些辅助函数,用于加密 / 解密构建在CryptoURSA之上的数据。
  • mad-science-weekend 分支↝我想在一个更接近现实世界的场景中测试所有这些东西; 所以我在我们的一个系统上找到了一个分支,它.pbf IPFS哈希而不是常规的AWS端点获取文件。

印象

这里有一些关于IPFS / IPNS和其他相关内容的一般印象,这些内容最终成为我研究的一部分 – 例如数据加密。

概观

如果您不需要 IPFS 101之类的任何内容,请跳过本节所有内容😎。

总之,它由分布式文件系统的对等协议组成。访问IPFS内容的最简单方法是通过其公共网关,很难在本地运行守护程序或自己的主机网关。

在将任何类型的数据(例如文件)添加到IPFS之后,它将成为所谓的对象。每个对象都有一个基于其内容生成的哈希值,并且可以通过它获得。

例如:

#如果将包含“hello worlds”的文本文件添加到IPFS:
> echo“hello worlds”| ipfs添加
#然后它将可用以下哈希:
添加QmZ4tDuvesekSs4qM5ZBKpXiZGun7S2CYtEZRB3DYXkjGx
> ipfs cat QmZ4tDuvesekSs4qM5ZBKpXiZGun7S2CYtEZRB3DYXkjGx 
ipfs

IPFS中包含的所有对象都是不可变的,这意味着如果需要添加新版本的文件,将创建一个新对象,完全不管前一个对象。然后获得一个全新的哈希 – 由于其不可改变的性质,前一个哈希仍然可用。

如果前一个示例中的文本更改为IPFS,我们将有一个新的哈希表示它:QmbXBAKDgbhE8HkGuEF4FuQQJej2mxqXtYSMsBPuJDqgjq

这是因为IPFS中存在强烈存在的内容可寻址存储的概念。也就是说,IPFS中的数据通过从其内容生成的一个哈希来解决,确保:

  • 更加诚信,无论在何处或谁提供内容。
  • 链接是永久性的 ; 总是指向同一个对象。

潜伏

tl;博士:负面。

尽管内容寻址的概念带来了许多好处,但最初它变得不适合需要不断获取某个内容的最后版本的情况,因为它需要在另一个版本中获取该对象的最后版本的哈希值渠道。

为了解决这个问题,开发了另一种称为IPNS的协议。使用peerID用户公钥的哈希,可以创建到特定对象的重定向。因此,出于教学目的,您可能希望将IPNS理解为对IPFS的永久不变性的少量可变性,因为它允许您存储对哈希的引用并通过简单地执行发布命令来更新该引用指向的内容。

中断:重要的是要强调这一点,因为我在这个 PoC上使用的平台上的内容每天都会在设定的时间与我们其他平台的数据同步。这意味着每天,Amazon Elastic Compute Cloud( AWS EC2上的机器人从我们的 MongoDB实例中读取数据,然后生成一些  .pbf文件,然后通过Amazon Simple Storage Service( AWS S3)提供服务

然后是另一个非常重要的细节:IPNS名称解析的延迟:根据学院中执行的测试,平均解决时间大约是10几秒钟 – 但很容易获得需要~30几秒钟的请求。这有点令人担忧,因为我们的日常工作包括尝试通过减少任何类型的延迟/等待时间/在最不同的Web开发层中的任何内容来改善用户体验 – 那么为什么我们会在地狱中包含DNS解析延迟?!

由于我们的地图平台前面提到的技术要求 IPNS的上述技术限制,使用CDN或常规静态文件托管服务 – 例如当前在AWS S3上运行- 以分布式方式存储和提供  .pbf数据 -顺便说一句,已经确保尽可能低的延迟 – 似乎更合适。

弹性

tl;博士:正面。

IPNS使用方面至少有趣的是名称可用时间。每当运行在AWS EC2实例上的机器人向IPFS添加新对象并创建其IPNS哈希重定向到新对象时,它就可以关闭其计算机中的守护程序。该IPFS节点,其中包括公共网关单,将继续保持在IPNS使用缓存系统地址。

换句话说,我们知道有人需要解析IPNS地址。我们也知道,这个人通常是IPFS哈希的所有者,他说“ 嘿,我的IPNS哈希指向那边的那个对象”。但是,IPFS网络还会缓存该名称的解析,因此如果该节点关闭,该IPNS散列仍然可以解析 – 顺便说一下,它的生命周期最长可达36小时。

对于我们的上下文,由于始终存在一个在IPFS中发布数据的活动实例,因此我们通常不必担心IPNS解析的到期。由于数据每次都会发生变化24h,而且36h即使我们遇到停机时间,其寿命也是如此,因此分辨率仍然可用。

这可能代表弹性的增加,因为经验不足的服务中断都不会影响.pbf数据的可用性  。

敏感数据

tl; dr:DEFINITELY需要更多的研究。

由于我们.pbf持有的数据非常敏感  ,因此有必要找到一种方法来确保只有我们可信赖的客户才能访问这些数据。

由于似乎有许多替代品 – 并且考虑到时间限制 – 我很难在其中一个之间做出选择。

说到IPFS本身,SWARM过滤器乍一看似乎是一个不错的选择,但我仍然不清楚它们是如何实验的。此外,我想到了私有网络 – 它只强制连接到只有拥有共享密钥的同行 – 但它也被记录为仍然是实验性的。

其他替代品 – 实际上是IPFS本身的替代品- 是专为私人使用而设计的 – 例如PeergosCamlistore

对于这个PoC,所选择的方法是在将文件添加到IPFS之前加密文件 – 我知道乍一看它似乎是一个天真的选择,但IPFS创建者Juan Benet已经提到他将这个策略用于他的个人文件。

虽然我们使用了一些很好的优化技术 – 例如这个轻量级的Protobuf实现和Brotli压缩算法 – 我们必须加密的数据量 – 大约8个  .pbf文件,其中包含来自数千个兴趣点(POI)的地理数据- 仍然被认为是大的由于URSA上的此问题,数据取决于RSA生成密钥的大小。

如下图所示,在此PoC期间的实验中,2^13字节大小的RSA密钥无法8使用URSA对我们的地理数据块进行加密- 顺便提一下,这是最常用的一种Node.js的OpenSSL绑定。

整天玩IPFS
所使用的RSA使用生成密钥genrsaOpenSSL 0.9.8上运行darwin64-x86_64-llvm(一MacBook Pro的内部8 GB 1867 MHz DDR32,7 GHz Intel Core i5)。

鉴于这些限制,我提出了基于对称密码的方法,使用内置于Node.js的简单AES 256加密


在一天结束时……

……我注意到我有很多乐趣🔝🌈🌟🎇🎆。

我有点看到Beakyn可能有很多好的案例,IPFS可能是一个很好的玩家 – 即使这个博客可以建立在它之上 – 但是,截至目前,并且考虑到这只是一个短暂的周末研究 – 所以不要把我视为分散的网络大师 – 我认为,对于帖子中描述的具体情况,所考虑的一切,都不合适,主要是因为当它到来时似乎增加了额外的关注层对等待时间敏感数据的安全性

最后但并非最不重要的是,非常特别感谢BrunoMarcus两位朋友 – 因为我非常关注所有的疑虑,并且总是可以进行涉及分散网络内容的长时间对话。


我想要学习的东西更多

这些是我想要阅读更多关于的一些主题/技术 – 每个都将导致不同的疯狂科学周末

强脉冲中子源 ↝我相信,更好地理解命名的分辨率下,引擎罩会帮助我能在延迟问题的解决进行合作,或至少理解它的根源。

Peergos↝作为一个建立在IPFS之上的点对点加密文件系统 -乍一看,在我看来,考虑到其私有共享设计目标,我似乎更接近于我们正在寻找的解决方案。

Camlistore↝再次,鉴于我肤浅的印象,在我看来,它似乎更接近我们正在寻找的解决方案。

Y.js↝离线优先p2p共享编辑对于我们的其他系统来说将是一件令人惊奇的东西 – 例如,它可以改进地图数据的创建。

OrbitDB↝鉴于其键值存储特性,在我们将堆栈迁移到分散堆栈的情况下,它可能是一个很好的MongoDB替代品。


参考和进一步阅读

  1. 亚马逊网络服务报告。(2017年)。北弗吉尼亚(US-EAST-1)地区的Amazon S3服务中断摘要
  2. Benet,J。(2015)。IPFS – 内容寻址,版本化,P2P文件系统
  3. 戴夫朗利(2013)。无法加密长度为256且具有2048位RSA的缓冲区问题#14
  4. Hartmann,C。(2014)。使用Nodej加密和解密内容
  5. IPFS(2016年)。首次了解IPFS后的问题·问题#154
  6. IPFS(2016年)。是否可以在ipfs中存储私有对象而不加密它们?·问题#181
  7. IPFS(2016年)。私人/个人使用ipfs?·问题#4
  8. IPFS(2016年)。密钥库/加密/ ipfs用例用于文件共享应用程序·问题#3866
  9. Macabeus,B。(2017)。IPFS和IPNS协议作为僵尸网络控制器的方式:概念证明
  10. Mutunhire,T。(2017年)。写入Node.js中的文件
  11. OrbitDB(2017)。orbitdb / orbit
  12. 里德,J。(2017)。IPFS / IPNS中的隐私和匿名
  13. 傀儡项目。(2016)。Golem Project Crowdfunding白皮书
  14. Zumwalt,M.,Johnson,J.,Benet,J.,Gierth,L。和Fisher,L。(2017)。分散式网络入门

点对点科技简介

点对点科技深耘IPFS与Filecoin技术,坚持区块链技术改变未来的信念。点对点 IPFS 数据中心是目前国内技术领先,性价比高、保障优的投资标的。自建杭州数据中心,合作数据中心分布于上海、宁波、河北、香港、斯德哥尔摩(瑞典)等地。点对点数据中心具有优秀的硬件配置与目前国内优质的网络节点资源。点对点科技力求将IPFS爱好者升级为IPFS领军者与受益者,让IPFS颠覆传统互联网,共同开启 WEB 3.0时代。

想了解更多区块链知识吗?关注我吧!

Filecoin测试网二阶段昨日重启,点对点出块第一! | 点滴资讯

原创文章,作者:Running,如若转载,请注明出处:https://ipfsdrop.com/tech/play-ipfs-all-day/

发表评论

电子邮件地址不会被公开。 必填项已用*标注