IPFS白皮书:用于构建web3.0的星际文件系统!
托管和分发PB级数据集;
跨组织的大数据计算;
大批量的高清晰度按需或实时媒体流;
大规模数据集的版本化和链接;
防止意外丢失重要文件等。
通过大量网络进行高效查询:查询平均联系人O(log2N)节点。(例如,20跳10万个节点的网络)
低协调开销:优化数量的控制消息发送到其他节点。
抵抗各种攻击,喜欢长寿节点。
在对等应用中广泛使用,包括Gnutella和BitTorrent,形成了超过2000万个节点的网络[16]。
Kademlia在ids为“最近”(使用XOR-distance)的关键节点中存储值。这不考虑应用程序数据的局部性,忽略“远”可能已经拥有数据的节点,并强制“最近”节点存储它,无论它们是否需要。这浪费了大量的存储和带宽。相反,Coral 存储了地址,该地址的对等节点可以提供相应的数据块。
Coral将DHT API从get_value(key)换成了get_any_values(key)(DSHT中的“sloppy”)中。这仍然是因为Coral用户只需要一个(工作)的对等体,而不是完整的列表。作为回报,Coral可以仅将子集分配到“最近”的节点,避免热点(当密钥变得流行时,重载所有最近的节点)。
另外,Coral根据区域和大小组织了一个称为群集的独立DSHT层次结构。这使得节点首先查询其区域中的对等体,“查找附近的数据而不查询远程节点”[5]并大大减少查找的延迟。
S/Kad 提供了方案来保证NodeId的生成已经防止Sybill攻击。它需要节点产生PKI公私钥对。从中导出他们的身份,并彼此间签名。一个方案使用POW工作量证明,使得生成Sybills成本高昂。
S/Kad 节点在不相交的路径上查找直, 即使网络中存在大量的不诚实节点,也能确保诚实节点可以互相链接。即使网络中存在一半的不诚实节点,S/Kad 也能达到85%的成功率。
BitTorrent的数据交换协议使用了一种bit-for-tat的激励策略,可以奖励对其他方面做贡献的节点,惩罚只榨取对方资源的节点。
BitTorrent对等体跟踪文件的可用性,优先发送稀有片段。这减轻了seeds节点的负担,让non-seeds节点有能力互相交易。
对于一些剥削带宽共享策略,BitTorrent的标准tit-for-tat策略是非常脆弱的。然而,PropShare[8]是一种不同的对等带宽分配策略,可以更好的抵制剥削战略,提高群集的表现。
不可更改的对象表示文件(blob),目录(树)和更改(提交)。
通过加密hash对象的内容,让对象可寻址。
链接到其他对象是嵌入的,形成一个Merkle DAG。这提供了很多有用的完整和work-flow属性。
很多版本元数据(分支,标示等等)都只是指针引用,因此创建和更新的代价都小。
版本改变只是更新引用或者添加对象。
分布式版本改变对其他用户而言只是转移对象和更新远程引用。
Location:代表的是服务网络地方
HostID = hash(public_key || Location)
身份 - 管理节点身份生成和验证。描述在3.1节。
网络 - 管理与其他对等体的连接,使用各种底层网络协议。可配置的。详见3.2节。
路由 - 维护信息以定位特定的对等体和对象。响应本地和远程查询。默认为DHT,但可更换。在3.3节描述。
交换 - 一种支持有效块分配的新型块交换协议(BitSwap)。模拟市场,弱化数据复制。贸易策略可替换。描述在3.4节。
对象IPFS是一个分布式文件系统,它综合了以前的对等系统的成功想法,包括DHT,BitTorrent,Git和SFS。IPFS的贡献是简化,发展和将成熟的技术连接成一个单一的内聚系统,大于其部分的总和。IPFS提供了编写和部署应用程序的新平台,以及一个新的分发系统版本化大数据。IPFS甚至可以演进网络本身。
文件 - 由Git启发的版本化文件系统层次结构。详见3.6节。
命名 - 自我认证的可变名称系统。详见3.7节。
type Multihash []byte // 自描述加密哈希摘要
type PublicKey []byte
type PrivateKey []byte // 自描述的私钥
type Node struct {
NodeId NodeID
PubKey PublicKey
PriKey PrivateKey
}
n = Node{}
do {
n.PubKey, n.PrivKey = PKI.genKeyPair()
n.NodeId = hash(n.PubKey)
p = count_preceding_zero_bits(hash(n.NodeId))
} while (p < difficulty)
1
传输层:IPFS可以使用任何传输协议,并且最适合WebRTC DataChannels [?](用于浏览器连接)或uTP(LEDBAT [14])。
可靠性:如果底层网络不提供可靠性,IPFS可使用uTP(LEDBAT [14])或SCTP [15]来提供可靠性。
可连接性:IPFS还可以使用ICE NAT穿墙打洞技术[13]。
完整性:可以使用哈希校验和来检查邮件的完整性。
可验证性:可以使用发送者的公钥使用HMAC来检查消息的真实性。
IPFS将地址存储为多层地址,这个多层地址是由字节字符串组成的, 以便于给底层网络使用。多层地址提供了一种方式来表示地址及其协议,可以封装成好解析的格式。例如:
# an SCTP/IPv4 connection
/ip4/10.20.30.40/sctp/1234/
# an SCTP/IPv4 connection proxied over TCP/IPv4
type IPFSRouting interface {
FindPeer(node NodeId) // 获取特定NodeId的网络地址。
SetValue(key []bytes, value []bytes) // 往DHT存储一个小的元数据。
GetValue(key []bytes) // 从DHT获取元数据。
ProvideValue(key Multihash) // 声明这个节点可一个提供一个大的数据。
FindValuePeers(key Multihash, min int) // 获取服务于该大数据的节点。
}
虽然易货系统的概念意味着可以创建虚拟货币,但这将需要一个全局分类账本来跟踪货币的所有权和转移。这可以实施为BitSwap策略,并将在未来的论文中探讨。
对等节点间会追踪他们的平衡(通过字节认证的方式)。
随着债务增加而概率降低,对等者概率的向债务人发送块。
为整个交易和节点最大化交易能力。
为了防止空负载节点利用和损害交易。
高效抵制未知策略。
对可信任的对等节点更宽容。
type Ledger struct {
owner NodeId
partner NodeId
bytes_sent int
bytes_recv int
timestamp Timestamp
}
type BitSwap struct {
ledgers map[NodeId]Ledger // Ledgers known to this node, inc inactive
active map[NodeId]Peer // currently open connections to other nodes
need_list []Multihash // checksums of blocks this node needs
have_list []Multihash // checksums of blocks this node has
}
type Peer struct {
nodeid NodeId
ledger Ledger // Ledger between the node and this peer
last_seen Timestamp // timestamp of last received message
want_list []Multihash // checksums of all blocks wanted by peer
// includes blocks wanted by peer's peers
}
// Protocol interface:
interface Peer {
open (nodeid : NodeId, ledger : Ledger);
send_want_list (want_list : WantList);
send_block(block: Block) -> (complete:Bool);
close(final: Bool);
}
Open: 对等节点间发送ledgers 直到他们同意。
Sending: 对等节点间交换want_lists 和blocks。
Close: 对等节点断开链接。
Ignored: (特殊)对等体被忽略(等待时间的超时)如果节点采用防止发送策略。
Peer.send_want_list(WantList)
当接收到一个want_list之后,节点会存储它。然后,会检查自己是否拥有任何它想要的块。如果有,会根据上面提到的BitSwap策略来将want_list所需要的块发送出去。
Peer.send_block(Block)
silence_wait超时已经过期,并且没有接收到来自于对等节点的任何信息(BitSwap默认使用30秒),节点会发送Peer.close(false)。
在节点退出和BitSwap关闭的时候,节点会发送Peer.close(true).
注意点:
非open信息在一个不活跃的连接上应该是被忽略的。在发送send_block信息时,接收者应该检查这个块,看它是否是自己所需的,并且是否是正确的,如果是,就使用此块。总之,所有不规则的信息都会让接收者触发一个close(false)信息并且强制性的重初始化此链接。
内容可寻址:所有内容都是被多重hash校验和来唯一识别的,包括links。
防止篡改:所有的内容都用它的校验和来验证。如果数据被篡改或损坏,IPFS会检测到。
重复数据删除:所有的对象都拥有相同的内容并只存储一次。这对于索引对象非常有用,比如git的tree和commits,或者数据的公共部分。
Name string // 此link的别名
Hash Multihash // 目标的加密hash
Size int // 目标总大小
}
type IPFSObject struct {
links []IPFSLink //links数组
data []byte //不透明内容数据
}
用对象的形式列出所有对象引用,例如:
XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x 189458 less
XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5 19441 script
XLF4hwVHsVuZ78FZK6fozf8Jj9WEURMbCX4 5286 template
解决字符串路经查找,例如foo/bar/baz。给出一个对象,IPFS会解析第一个路经成分进行hash放入到对象的link表中,再获取路径的第二个组成部分,一直如此重复下去。因此,任何数据格式的字符串路经都可以在Merkle DAG中使用。
递归性的解决所有对象引用:
/XLZ1625Jjn7SubMDgEyeaynFuR84ginqvzb
XLLxhdgJcXzLbtsLRL1twCHA2NrURp4H38s
XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x
XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5
XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z
键值存储
传统关系型数据
数据三倍存储
文档发布系统
通信平台
加密货币区块
# 格式
/ipfs/
/ipfs/
Object []bytes // 已加密的原始对象数据
Tag []bytes // 可选择的加密标识
type SignedObject struct {
Object []bytes // 已签名的原始对象数据
Signature []bytes // HMAC签名
PublicKey []multihash // 多重哈希身份键值
}
Block:一个可变大小的数据块
List:块或者其他链表的集合
Tree:块,链表,或者其他树的集合
Commit:树在版本历史记录中的一个快照
我原本希望使用与Git对象格式一致的模型,但那就必须要分开来引进在分布式文件系统中有用的某些特征,如
快速大小查找(总字节大小已经加入到对象中)
大文件的重复删除(添加到list对象)
commits嵌入到trees中。
{
'data': 'some data here', // blobs无links
}
{
'data': ['blob', 'list', 'blob'], //lists有一个对象类型的数组作为数据
'links': [
{ 'hash': 'XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x',
'size': 189458 },
{ 'hash': 'XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5',
'size': 19441 },
{ 'hash': 'XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z',
'size': 5286 } //在links中lists是没有名字的
]
{
'data': ['blob', 'list', 'blob'],//trees有一个对象类型的数组作为数据
'links': [
{ 'hash': 'XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x',
'name': 'less', 'size': 189458 },
{ 'hash': 'XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5',
'name': 'script', 'size': 19441 },
{ 'hash': 'XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z',
'name': 'template', 'size': 5286 }//trees是有名字的
]
}
构建一个Git工具版本改造成使用IPFS对象图,
构建一个挂载FUSE文件系统,挂载一个IPFS的tree作为Git的仓库,把Git文件系统的读/写转换为IPFS的格式。
就像在LBFS[?]中一样使用Rabin Fingerprints [?]来选择一个比较合适的块边界。
使用rsync[?] rolling-checksum算法,来检测块在版本之间的改变。
允许用户指定专为特定文件而调整的’快分隔’函数。
tree缓存:由于所有的对象都是哈希寻址的,它们可以被无限的缓存。另外,trees一般比较小,所以比起blobs,IPFS会优先缓存trees.
flattened trees:对于任何tree,一个特殊的 flattened tree可以构建一个链表,所有对象都可以从这个tree中访问得到。在flattened tree中名字就是一个从原始tree分离的路径,用斜线分隔。
{
'data':
['tree', 'blob', 'tree', 'list', 'blob' 'blob'],
'links': [
{ 'hash': '
'name': 'ttt222-name' },
{ 'hash': '
'name': 'ttt222-name/bbb111-name' },
{ 'hash': '
'name': 'ttt333-name' },
{ 'hash': '
'name': 'ttt333-name/lll111-name'},
{ 'hash': '
'name': 'ttt333-name/lll111-name/bbb222-name' },
{ 'hash': '
'name': 'bbb222-name' }
] }
这值得详述原因—如果最终易变数据是必须的—我们费了很大的力气构建了一个不可改变的Merkle DAG。就当做IPFS脱离了Merkle DAG的特征:对象可以(a)通过哈希值可以获取,(b)完整性的检查,(c)link其他的对象,(d)无限缓存。从某种意义上说:对象就是永恒的。
回想一下在IPFS中:
NodeId = hash(node.PubKey)
我们给每个用户分配一个可变的命名空间,在此路径下:
/ipns/
一个用户可以在此路径下发布一个用自己私钥签名的对象,比如说:
/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/
当其他用户获取对象时,他们可以检测签名是否与公钥和NodeId匹配。这个验证了用户发布对象的真实性,达到了可变状态的获取。
IPNS(Inter Planetary的命名空间)分开前缀是在可变和不可变的路径之间建立一个很容易辨认的区别,为了程序也为了人类阅读的便利。
因为这不是一个内容可寻址的对象,所以发布它就要依靠IPFS中的唯一的可变状态分配制度,路由系统。过程是(1)首先把此对象做一个常规的不可变IPFS的对象来发布,(2)将此对象的哈希值作为元数据的值发布到路由系统上:
routing.setValue(NodeId,) 发布的对象中任何links在命令空间中充当子名称:
/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/
/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/docs
/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/docs/ipfs一般建议发布一个commit对象或者其他对象的时候,要使用历史版本记录,因为这样就用户就可以找到之前使用过的名字。不过由于这并不总是需要的,所以留个用户自己选择。
ipfs link /
# Eve links 到Alice上
ipfs link /<eve-pk-hash/friends/alice /
# Eve 也可以访问Bob
/<eve-pk-hash/friends/alice/friends/bob
# 访问Verisign 认证域
/
# DNS TXT 记录
ipfs.benet.ai. TXT 'ipfs=XLF2ipQ4jD3U ...'
# 表现为符号链接
ln -s /ipns/XLF2ipQ4jD3U /ipns/fs.benet.ai
# proquint语句
/ipns/dahih-dolij-sozuk-vosah-luvar-fuluh
# 分解为相应的下面形式
/ipns/KhAwNprxYVxKqpDZ
# 用户可以从下面获取一个link
/ipns/shorten.er/foobar
# 然后放到自己的命名空间
作为一个挂载的全局文件系统,挂载在/ipfs和/ipns下
作为一个挂载的个人同步文件夹,自动的进行版本管理,发布,以及备份任何的写入
作为一个加密的文件或者数据共享系统
作为所有软件的版本包管理者
作为虚拟机器的根文件系统
作为VM的启动文件系统 (在管理程序下)
作为一个数据库:应用可以直接将数据写入Merkle DAG数据模型中,获取所有的版本,缓冲,以及IPFS提供的分配
作为一个linked(和加密的)通信平台
作为一个为大文件的完整性检查CDN(不使用SSL的情况下)
作为一个加密的CDN
在网页上,作为一个web CDN
作为一个links永远存在新的永恒的Web
一个IPFS库可以导出到你自己应用中使用
命令行工具可以直接操作对象
使用FUSE[?]或者内核的模型挂载文件系统
声明:此文出于传递更多信息之目的,并不意味着赞同其观点或证实其描述。本网站所提供的信息,只供参考之用。
-
FIL大涨,灰度入局,如何参与IPFS挖矿
2021-03-23 IPFS挖矿 -
【重磅】A股上市公司斥资5.8亿布局IPFS分布式存储项目
2021-03-17 IPFS -
IPFS官方@你 | 第125期周报
2021-03-08 IPFS -
IPFS周报124期:go-ipfs 0.8.0, 远程数据固定来了!
2021-02-24 IPFS -
最新消息 | Fleek在IPFS上存储和提取文件
2021-02-24 IPFS
更多 推荐专栏
- 吴说区块链
- 知名自媒体,作者曾获中国新闻奖。为您提供加密行业、科技公司独家可靠的信息与观点。
- 挖币网评测
- 挖币网专业测评
- 区块鲁班
- 元宇宙工程师——区块鲁班,是一个具备全球化服务能力的公司品牌。提供矿机采购、维修、测试、托管、运维、出口等一站式服务。我们与比特大陆、比特微、嘉楠国际、芯动科技等全球头部矿机生产厂家建立了良好的合作关系,共同开创矿机国际化服务标准,并携手在全球布局矿机服务中心,为全球加密货币行业参与者提供专业、高效、全面的解决方案。
- HashPool
- 多币种数字货币矿池,关注最新最有潜力币种 HashPool 链接每一个算力
- 巴比特资讯
- 巴比特是国内领先的区块链信息服务商,以价值投资为导向,为区块链创新者服务。 我们以论坛启锚远征,让资讯为瞭望景观,聚集区块链技术和应用弄潮儿。目前已发展成集资讯内容、线下活动、培训、孵化器、投资和区块链技术落地应用于一体的生态体平台。全网覆盖用户超100万人,遍及中国大陆、韩国,日本,美国,香港等国家和地区。