IPFS协议层深入分析12(完结篇)

上一节我们讲解了Naming协议层在实践中的意义,本节我们将讲解该层的具体实现,首先我们来看一下该层的接口定义,如下图:

该层的接口定义比较简单,一个解析接口和2个发布接口,他们分别对应上节案例中的publish和name resolve功能。其具体实现逻辑如下:

当应用层将ipfs协议下的Hash值发布到网络时,首先ipfs节点会读取自己的ID,然后在本地存储中查找关于该ID的IPNS的映射数据,如果查找成功,则更新该数据的序列号,然后调用Routing协议层的PutValue接口,将本ID和最新的IPNS映射关系数据发布到全网;如果在本地存储查找失败,则先调用Routing协议层的GetValue方法,从全网查找关于该ID对应的IPNS映射数据,如果查找成功,更新数据的序列号并重新发布到全网,如果从全网查找映射数据失败,则新建一个关于该ID与IPNS的映射数据并发布到全网。

当应用层要解析IPNS协议下的某个ID对应的IPFS Hash数据时,Naming层首先从本地的Cache中查找对应的映射数据,在上面的Publish环节中,如果Routing协议层PutValue成功,Naming层会将映射数据缓存在本地的Cache中,因此每次resolve首先会从本地缓存读取,这样可以有效的减少网络访问成本。如果从缓存查找失败,则Nanming层将会向Routing协议层发起GetValue的网络访问请求,如果访问成功,则应用层会收到关于该ID的Hash值,然后用户就可以通过该Hash值访问具体的数据内容。

Naming层的具体实现相对简单,因为基于已经成熟的Merkle Dag层和Routing层,数据交换层的API接口,可以实现固定Name与可变数据hash值之间的映射与映射数据的查找。虽然相对简单,但是其应用场景缺比较丰富且有趣,下面我们将以一个无线扩容的存储挂载带你为例,讲解一下其使用方式,相比于上一节讲解的去中心化网站,本节讲的去中心化无限扩容网盘会更有意思一些。

我们以Linux操作系统的目录结构为例,首先要启动ipfs的守护进程,并且调用ipfs的mount命令,将整个IPFS网络mount到 "/" 目录下(mount到那些目录可以随意),如果成功则会出现一个"IPFS"目录,此时整个IPFS网络就会为你提供网络存储服务,通过Naming协议,任何添加到该目录下的文件和文件夹都会被映射到IPFS网络可以识别的HASH值。这样任何加入到IPFS网络的,各式各样的存储设备就可以为你提供无限制的数据存储服务。

对于公链项目,如果能在此网络的基础上增加激励机制,就可以充分调动大家的积极性,将闲置的存储资源贡献出来获取代币奖励,并且对于使用者来说,也可以通过支付代币的方式灵活的获取数据的存储与读取服务,并且这种付费的计算精度可以非常精准,这意味着大家不用购买冗余的存储空间,可以做到用多少就付多少钱的效果,这样可以做到及其精准的共享计费。

对于企业级用户来说,搭建这样的存储公司内网,可以充分的利用公司闲置的IT设备资源,对于大的集团公司,往往有海量的数据存储,并且数据是分为不同的等级的,对于那些并不是特别重要但是数量又庞大的数据,租用商业的存储空间极其昂贵,性价比很低;与此同时公司内部的IT设备会面临资源浪费,淘汰或者闲置的情况,使用此技术方案搭建一个存储私有网络,既可以充分利用公司的闲置资源,又可以满足公司的存储需求。

根据前几节讲解的内容,数据是被分配并加密存储在所有节点上,因此数据的安全性和保密性可以得到充分的满足,因此使用此协议也无需担心数据泄露的问题。

在数据的传输过程中,为了防止抓包软件对数据的偷听,通过以下协议可以解决数据再传输过程中的安全问题。

首先是作为客户端的IPFS节点发起内容访问请求,服务器端会给出自己的公钥,客户端收到公钥之后,将自己的公钥发送给服务器,并且随机生成2个公钥C1和C2,然后用服务的公钥对这两个新的公钥进行加密,将加密数据传送给服务器,服务器收到数据后,用自己的私钥将公钥C1和C2解密,同时自己也随机生成2个公钥S1和S2,并将这两个新的公钥用客户端的公钥加密,将加密数据发送给客户端,客户端收到加密数据后,用自己的私钥解密。

以后的每次数据传输,客户端到服务器端发送数据都要使用公式1用到的数据进行签名,服务器到客户端的数据都要使用公式2中的数据进行签名,这样可以杜绝恶意节点对于数据的修改和破坏。

到本节为止,关于IPFS的深入架构分析告一段落,除去IPFS的网络层没有进行深入的分析和研究,其它协议层都已经分析完毕,本节结合应用实例讲解了Naming协议层的实现,因此应用层其实夹杂在了本层协议的讲解中。接下来的工作我们会根据时间安排来讲解IPFS网络层(最底层)的实现,并且开启NBS(Next Blockchain System 我们的公链项目)对IPFS协议全面重构,以满足我们应用场景的需要,这个过程中,我们会开发对应的DAPP来测试我们重构的效果和网络的性能,敬请期待接下来更精彩的文章《NBS对IPFS协议的重构》。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,324评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,303评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,192评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,555评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,569评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,566评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,927评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,583评论 0 257
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,827评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,590评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,669评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,365评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,941评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,928评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,159评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,880评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,399评论 2 342

推荐阅读更多精彩内容