写点什么

DSN 主流项目调研 0——IPFS&&Filecoin 白皮书总结

用户头像
AIbot
关注
发布于: 2020 年 08 月 12 日
DSN 主流项目调研 0——IPFS&&Filecoin白皮书总结

IPFS&&Filecoin总结



AIbot 2020-07-31

IPFS的总结



总结架构介绍



IPFS项目是ProtoLab实验室推出的第二大开源项目,依托实验室之前推出的MultiFormat、Libp2p和IPLD三个项目组织而成。



其中MultiFormat是自描述格式协议库,主要负责解决各种编程语言和数据类型难以详细区分而诞生的, 其为其他四个项目的基础;Libp2p项目是点对点通信库,主要负责解决分布式系统中异构设备之间建立网络通信的工作,它是IPFS项目最重要的模块;IPLD是基于内容寻址的数据模型的抽象层,主要负责解决各种分布式系统的数据模型各不相同和难以互相沟通的问题,它在和区块链系统的集成中发挥重要作用。



回到IPFS本身来说,IPFS自顶向下的项目架构如图1.1 项目架构图所示,最两层为文件相关的,其中命名层直接和用户沟通,利用IPLD中子认证文件系统SFS实现了可更改的文件系统MFS,方便用户的使用。文件相关的另一层是对象文件层,主要涉及文件在IPFS中的具体存储逻辑,包括Merkle-DAG的组织和Git的版本控制。另外三层是与点对点网络相关的;其中和用户最直接相关的是交换层,交换层通过bitswap采用自定义的激励策略实现文件的点对点交换分发。点对点网络相关的第二层是身份路由层,使用K/Skalemila算法来确定对等节点的身份哈希,使用tree cache和Flatten tree的方式加速DHT节点的定位和对象存储的地址的记录。点对点网络相关的最底层是网络层,网络层负责异构设备间的点对点通信可扩展的网络协议以及NAT(目前一层)





图1.1IPFS项目架构图



文件层的介绍



命名层



简介



命名层设计一个自认证的文件系统概念Self-certificate FileSystem;该系统有如下两个特征:安全性和可扩展性;还通过指针的方式实现了文件易变状态固定也即是常说的IPNS在此基础上建立了类似于当前互联网的DNS查询机制,实现了了人类容易记住的方式来访问文件对象。



SFS简要介绍



安全性



在SFS中通过将公钥信息嵌入到文件中建立初始的加密通信通道,再经由加密通信通道进行数据的传输来保证公网环境下分布式文件系统的安全性,而加密通信通道中密钥的安全性将由第三方公司提供的文件系统来访问经过认证的文件服务器保证密钥的安全



可扩展性



三个属性实现可扩展性:全局的命名空间,任何服务器都可以加入进来但是不会受到任何的访问限制和控制;密钥管理的原语集:不同用户客人已采用不同方案的技术来认证i相同的服务器(只要服务器支持);模块化设计:软件角度方便可扩展



IPNS简要介绍



IPFS形成了一个内容可寻址的DAG对象, 当数据对象的内容更新后, 同时发生改变的还有内容地址的名称。 我们需要一种能在易变环境中保持固定名称的方案,为此, 协议实验室团队为IPFS设计了IPNS星际文件命名系统模块。 并在此基础上使用对等节点链接、DNS TXT IPNS记录两个设定进一步增强了用户友好度



对等节点链接



遵循自验证文件系统(SFS) 的设计理念, 用户可以将其他用户节点的对象直接链接到自己的命名空间下; 这也有利于创建一个更可信的网络。





DNS TXT IPNS记录



我们也可以在现有的DNS系统中添加TXT记录, 这样就能通过域名访问IPFS网络中的文件对象了。



   # DNS TXT 记录   ipfs.benet.ai TXT "ipfs=XLahueaavfbf..."    # 表现为符号链接    ln -s /ipns/XLahueaavfbf... /ipns/fs.benet.ai

IPFS还通过Proquint可读标识符实现将二进制编码翻译成刻度文件



# Proquint 语句 /ipns/dahih-dolij-sozuk-vosah-luvar-fuluh # 分解为相应的形式 /ipns/KhAwNprxYdafsfa

对象文件层

简介



对象文件层采用Merkle-DAG的方式来组织文件的存储使用blob为最小的存储单元,blob的大小可以设置为固定值也可以使用IPFS自行设计的Rabin算法计算;其中文件使用类似于git的方式组织也包含:blob、list、tree、commit的概念。同时介绍了一种优化查找性能的方法 tree cache和Flatten tree

Merkle-DAG

比较Mekle-Tree



虽然二者都是hash组建的树形结构并且tree可以认为是一种特殊的DAG但是二者的使用功能上却各有长短:tree更加适用于文件指纹的验证过程、而DAG则可以在存储的去重领域大显身手

Merkle-DAG的结构



在IPFS中DAG节点包含两个部分:Data和link, LInk部分又由Name、hash、size三块组成;其中Data当然是保存本块的数据,而link则用于保存本数据分块的链接引用,并不会重复存储一个IPFS对象。

好处



使用Git和Merkle DAG相结合可以极大减少存储空间的消耗,对源文件的修改使用Merkle DAG存储的对象,只需要要对子数据块中存储的内容进行修改并对文件的指针进行移动,既不需要修改前对文件备份,也没必要修改整份文件。如果是没有pin过的数据一定周期后IPFS会自动丢弃(具体遗忘周期可自定义)

Git文件存储

结构介绍



Git中文件将有Blob、List、Tree、Commit四个概念取维护,实际上一份文件会划分程多个Blob,Blob的大小从32B到256B不等,具体实践中可以是固定的划分大小也可以是Rabin算法自动划分的,一般将属于同一个文件的Blob组成一条Blob list也就是所谓的Flatten tree。这样可以实现更快查找速度,于是将不同的list组建文件树;而每一个Commit其实就是整个树的快照,至于用户可见的命名空间只需要只想最近的文件快照的merkle根就可以了。



性能优化的方法



树缓存tree cache,由于树只存各个list 的hash值,因此会比blob小的多;因此缓存树既可以提升系统的查找速度又不会造成太多的存储空间的浪费。



另一个性能优化的方法是扁平树Flatten树,扁平树的本质就是将原来的树型结构压回到list形式来加快查询的速度。 扁平树的产生中到底带来了哪方面的开销???虽然直觉上可以加快查询速度, 但是从总体来看就变成顺序遍历了吧?



网络层的介绍



交换层



简介



交换层中使用自研的BitSwap模块进行数据的分发和交换;利用收发比来作为sigmoid的自变量,设置四种(?实际只找到了三种)不同的发送策略来激励和惩罚节点收发比1:3就可以获得不错的接受激励,收发比1:1所获得一般的接受速度。另外借用原有的bittorrent的算法——片段选择策略、阻塞策略。



片段选择策略



  • 优先完成单一片段

  • 优先传输稀有片段

  • 首个片段随机选择

  • 结束后去取消片段



阻塞策略



每一个Peer最多和四个Peer相连接



  • Bittorren阻塞:t每十秒计算一次最大连接速度,判断节点的连接状态,保证网络的公平

  • 最优阻塞:每隔30s打断一下网速最快的收节点

  • 反对歧视:一直作为收节点享受不到高速服务就停止贡献上传资源



Bitswap激励策略



拒绝上传chocking:临时中断对贪婪节点上载数据



帕累托最优Pareto:各方均满意的一个中庸速度



争锋tit-fot-tat:一报还一报的上传下载速度



身份路由层



简介



路由层主要负责DHT分布式哈希表的维护,在私有的IPFS集群中也可以使用HT的方式来获得更加稳定可靠高效的服务。在实际的组织过程中会使用Coral DSHT算法中的值存储规则,将<1KB的数据直接存储在DHT中,而其他较大的数据会存储数据所在节点ID;值得一提的是DHT是搜耦合的、支持自定。再加入DHT的时候需要进行身份的核验。



DHT的合理组织有赖于合理的身份认证方式,朴素的Kademlia算法虽然提供了高效的检索方式和路径计算方法但是没有考虑吧实际的网络情况,而Coral DSHT的提出弥补了朴素的路径计算方法,考虑了更全面的互联网联通抢矿可以认为是Kademlia的xor的加权距离计算方法。在原有Kademlia算法基础上升级的S/KKademlia算法是通过对于节点身份ID的绑定和创建成本要求,防止日蚀、女巫、流失、对抗路由攻击



网络层



简介



网络层是IPFS的基础核心层级,通过网络层提供的高性能p2p模块,实现了IPFS系统的鲁棒性和异构能力。支持主流的网络传输协议,NAT技术能够让内网中的设备公共一个外网IP;multiaddr技术实现了网络协议的兼容和扩展、覆盖目前主流的网络模型





组件



transport传输层、upgrader升级层、relay中继层、peerStore记录层、Swarm管理层、host接口层




FileCoin的总结

总体协议流程



简介



Filecoin链需要撮合客户-存储矿工和客户-检索矿工这样两种关系,其中客户-存储矿工的关系更多的涉及区块链的操作,而客户-检索矿工的关系只在订单匹配以及支付过程需要filecoin的支持;另外值得一提的是Filecoin本质并不是发币机制而是交易所法币挂钩机制,因此filecoin和比特币等发币的区块链从设计宗旨上来说是完全不同的。



流程



  • 订单簿(Order) : 用户和矿工之间的交易订单的集合, 用来记录用户和矿工之间的交易信息。

  • 转账记录(Transactions): Filecoin代币的转账记录, 跟比特币的交易记录一样。

  • 分配表(AllocTable) : 该表记录着全网所有矿工的数据存储情况。



如下图5-2Fileoin的协议流程所示,简单来说,Filecoin中各角色的分工如下:客户付钱存储数据、存储矿工专门存储、检索矿工专门检索



核心组件



通过以上描述可以直观的发现区块链作为可信第三方平台的磋商机制是保证整个系统平稳运行的核心,除此以外证明矿工尽力工作的PoRep以及PoSt也不可或缺



因此就不难发现在Filecoin中交易磋商机制和PoS机制(无论是Porep还是Post本质上都是POS,这里是storage充当Stack)



交易流程介绍



以存储交易过程为例介绍Filcoin存储数据的交易磋商过程,其中包括OrderMatching和Settlement两个过程;其中无论是矿工还是客户都需要经历Ordermatching的阶段以签订Deal订单为止表示双方对交易细节满意,而Settlement则是矿工为了证明自己真是存储了Replica数据副本而做的PoRep(首次)和PoSt证明(之后)文件生成。



OrderMatching流程介绍



通过图2.1Ordermatching流程图可以看出,Ordermatching阶段客户端和存储矿工都要进行订单的发送,对于客户端而言,需要保证余额充足的情况下发送BidOrder订单到链上记录在Orderbook中;对于矿工而言需要线性抵押自己的存储空间后采用发送askOrder接单订单。当OrderBook中两种订单的期望价格达成了已知就会先让客户端节点发送带存储的数据碎片给存储矿工,存储矿工获得数据碎片后,根据客户端的订单生成交易订单并签名,签名后将交易订单发送给客户端,客户端接收到交易订单后用自己的私钥签名表示认可该交易发送给区块链。区块链验证并记录这个歌deal order的合法性记录在OrderBook,视为完成了整个订单匹配的交易。





Settlement流程介绍



如图2.2Settlement流程图所示当存储矿工成功的接到一笔订单后需要立即对数据进行seal操作生成数据的副本来面对网络提出的挑战,密封操作需要矿工的密钥、扇区的序列号和当前的分配表。经过密封操作后生成了一个





密封证明和副本的跟哈希



矿工生成好存储证明后PoRep,矿工将存储证明过程中生成的两个输出提交给网络进行校验,具体校验过程见PoS过程介绍中的PoRep部分。在矿工分配好数据生成副本后,矿工还需要持续生成存储证明,以确保他们没有在两次提交证明之间丢失数据,生成的存储证明会同步到区块链中接受全节点 的验证(一般意义上存储矿工就是全节点,在FIlecoin中将全节点又称为Network网络)



时空证明:、和副本的额根哈希



如果时空证明的证据缺失,依据确实情况有不同的处理策略:第一种策略只要存在证据确实就会触发:扣除矿工抵押的存储空间、第二种策略会在验证proof失败次数超过阈值后触发:生成新的数据存储订单(按照备份的存储复制)、第三种策略是在全部的proof验证失败的情况下触发:退还存储者的存储资金,并将相关责任人踢出网络。

Network发挥的作用



分配订单



Manage.AssignOrders用于分配订单, 其输入为成交单, 以及当前配置表。 新的订单会首先经过合法性校验, 随后添加到新的分配表中。





Manage.RepairOrders用于修复订单, 其输入为当前时间戳、 当前账本, 以及当前配置表AllocTable。 执行Manage.RepairOrders后, 对于配置表中每一条AllocEntry, 如果还没有到需要检查的时间, 那么直接跳过; 如果需要检查, 则进行如下操作: 首先更新此AllocEntry的时间戳, 并检查时空证明是否合法(是否在规定时间之内反馈, 是否对应该文件片段, 能否通过可验证时延加密的验证) ; 如果该条目失效时间过长, 标记为失效订单; 同时尝试重新发起该订单; 最终输出修复后的配置表。



修复订单



:输入:当前时间,当前账本,当前配置表输出:新的配置表,修复后的订单过程:)对于中每一个条目①如果不到下一次挑战时间,跳过②更新③中,提交时空证明时间在限制之内,并且合法检查通过,标记该条目为合法检查失败,标记该条目为非法,并惩罚该矿工的担保品④如果失效时间长于,标记为失效订单⑤尝试重新发起该订单)输出更新后的配置表,修复后的订单



POS运算规则介绍



POS和PoRep、PoSt的关系



Filecoin中的PoRep和PoSt证明本质上是一种POS(Proof of Stack, 其中Stack为Storage)。存储证明关系图见图2.2存储关系图



PoRep详细介绍



是什么



允许P生成存储D的n个不同副本(物理上独立的副本)的证据Πproof;并且确保验证者V相信信P确实独立的存储了每个副本的完整数据的一种证明生成方法。



为什么



当前的POS算法无法同时应对女巫攻击、外包攻击和生成攻击。



•女巫攻击Sybil Attacks矿工对网络宣称他保存了一份数据的n份备份, 实际上该矿工通过创建多个节点(女巫攻击) 的方式,实际上只保存了该数据的一份备份。 当检验者检验的时候, 该矿工使用一份备份完成所有检验, 即可达到攻击的行为。



•外包攻击 Outsourcing Attacks矿工对网络宣称他保存了一份数据的n份备份, 实际上该矿工通过多个矿工共享数据(外源攻击) 的方式,实际上只保存了该数据的一份备份。 当检验者检验的时候, 该矿工使用一份备份完成所有检验, 即可达到攻击的行为。



•生成攻击 Generating Attacks当网络发起挑战的时候, 恶意节点使用某种方式临时生成数据, 而其实际存储的数据量小于对网络宣称的数据量, 攻击成功。



怎么办



抽象解决方法



顺利通过复制证明测试的所有方法均可被称为PoRep方法,具体的Fielcoin选择了一张加密块链结合伪随机置换的方法来实现PoRep。



已知条件攻击者:有个空间、验证者:要存储个空间数据、供应商:免费提供无尽存储空间、待检验的方案:验证过程:任意存储数据、:有许多女巫身份、:数据存储者并验证是否真存了?



具体的解决方法



其他



EC期望共识简介



设计原则



有用的共识竞争



简要描述



选举矿工



  1. 根据矿工的当前实际存储数据的量选举

  2. 建模挖矿权力



期望共识的设计



选举特点



决定性的、无法预测、秘密; 概率性共识



选举矿工过程



  • 



  • 



验证算法细节



网络节点每接受一个新的区块, 即可开始验证它。1) 验证签名的合法性, πit是否由i矿工签名。2) 检查Pti是否是t时刻i矿工的存储算力。3) 检查对应存储算力下密码学问题是否通过 。



更多详细细节参考论文: CoA、 Snow White、Algorand



Bridge项目



Filecoin连接其他平台其他区块链系统,



例如Bitcoin、 ZCash, 尤其是Ethereum, 它们允许开发人员编写智能合约, 因为区块链将数据进行了大量备份, 在这些系统上进行存储的成本会很高昂。 Bridge能将Filecoin的存储和检索功能带入其他区块链系统。 目前, 这几个智能合约已经使用IPFS作为内容存储和分发, 后续升级后会通过交换Filecoin方式, 保证存储内容可用性。



其他平台连接Filecoin



其他区块链系统的特性也能在Filecoin上使用。 例如,利用ZCash集成隐私数据分发等。



发布于: 2020 年 08 月 12 日阅读数: 71
用户头像

AIbot

关注

西风不起, 东风赐祚 2020.04.10 加入

默默无闻的CODER

评论

发布
暂无评论
DSN 主流项目调研 0——IPFS&&Filecoin白皮书总结