简介

Tendermint 是分布式一致性软件。即使有1/3的机器叛变了， 也能保证其余机器上的数据一致。容忍机器以任意方式失败的能力， 包括变得恶意， 被称为拜占庭容错(BFT)。该理论被提出来数十年了，由于bitcoin和ethereum”区块链技术”的成功，才变得流行起来。区块链用点对点和加密认证技术组成了一个现代化BFT实例。Tendermint包含了两个主要的组件：区块链共识引擎和通用应用层接口。共识引擎叫Tendermint Core，确保每一台机器上的交易列表相同。应用层接口名字是ABCI，提供能为任何语言处理交易的接口。与其他区块链的解决方案（内置的状态机预先打包块）不同，如ethereum的基于世界状态树的键值对存储、bitcoin的脚本语言处理。开发人员可以在任何开发环境下用任何语言通过实现ABCI应用层来复制Tendermint状态机。

共识算法

Tendermint 是一个易于理解的，大部分模块采用异步通信的，拜占庭容错共识协议。该协议可用一个简单的状态机表示，如下图：

协议参加者称为验证节点；他们轮流打包出块并集体对该块打包。在每一个高度上只允许一个块commit。在一个块无法在该轮被提交的情况下，协议会移动到下一轮，并且新的验证节点会propose一个该高度的块。需要两轮投票才能commit一个块；这两轮投票我们称为“pre-vote“ 和 “pre-commit“。在每一轮投票中需要超过2/3的验证节点对同一个块pre-commit才能最后的块commit。
验证者在每一轮中commit块时会失败，原因如：当前提议者可能离线，或者网络可能很慢。Tendermint允许跳过验证者，验证者等待一小段时间从proposer收到完整的proposer块，然后进入下一轮投票。这种对超时的依赖使得Tendermint成为弱同步协议，而不是异步协议。然而，协议的其余部分是异步的，验证者只有收到超过2/3的投票后才能取得进展。precommit和propose两轮投票机制是一样的。
假设有不到三分之一的验证节点是拜占庭节点，Tendermint保证不会违反安全性。也就是说，验证节点永远不会在相同的高度提交冲突的块，不会分叉。为此，它引入了一些“锁定“规则。一旦验证器预先插入一个块，它将被锁定在该块上，然后，

• 1.prevote的块必须是被锁定的。
• 2.precommit一个新块后，验证者才能解锁。

  股权

  并非所有系统中的验证者有相同的权重。因此，我们对1/3或2/3的验证者并不感兴趣，但在总投票权的比例中，这些比例可能不会在单个验证者中统一分配。由于Tendermint可以实现任意应用程序，因此可以定义货币，并以该货币计价投票权。当投票权以本币计价时，系统通常被称为PoS。验证者可以通过应用程序中的逻辑强制将其货币持有量“绑定”在可能被破坏的PoS中，如果它们在协商一致的协议中被发现存在不正当行为。这为协议的安全性增加了经济因素，允许人们量化违反不到三分之一的投票权是拜占庭的假设成本。

  基于Tendermint的应用架构

  区块链应用不仅仅包括共识引擎和交易逻辑（如，智能合约，商业逻辑）。同时也包括（手机端， web端，桌面端）链接上的应用。在这些链接中安全很重要，DoSed攻击是通过攻破的1/3的验证节点去攻击其他2/3的验证节点。一种常见的攻击就是ABCI应用和tendermint core之间的通信。所以ABCI应用和tendemint core之间的通信安全性很重要。通信安全由强到弱 unix socket > local tcp socket > vpn > 外网tcp socket。
  通用的应用框架如下图：
  
  优点
• 应用层和区块链层相分离。
• 支持更丰富，更灵活的客户端API。
• 支持pub-sub模式，观察关键字段等。
  注意点
• 直接调用ABCI接口非常危险（写数据接口调用时需要非常小心，除非来自验证节点的消息）
• 不能直接访问区块链的头和验证交易。
• 自己必须实现自己的API。

  应用层开发

  ABCI的目的在一台交易处理状态机和多台提供复制机制的计算机之间提供清晰的接口。前者称之为“应用逻辑“， 后者称之为“共识引擎“。应用程序逻辑验证事务，并可选地针对某些持久状态执行事务。共识引擎可确保在每台机器上以相同的顺序复制所有事务。我们将共识引擎中的每个机器称为“验证器”，并且每个验证器通过相同的应用程序逻辑运行相同的事务。特别是对区块链的共识引擎，其中交易在链式哈希块中提交。
  ABCI的设计有几个不同的模块：
• 消息协议
• 1.一对请求和响应消息。
• 2.共识提出请求，应用响应。
• 3.使用protobuf的定义。
• server/client
• 1.共识引擎作为client端运行。
• 2.应用程序作为server端运行。
• 3.两个实现：
• a.异步raw字节。
• b.grpc。
• 区块链协议
• 1.abci是面上链接的。
• 2.Terdermint Core 维护了三个链接：
• a.mempool链接：CheckTx
• b.consensus链接：交易列表执行后打包提交，消息队列对于每个块：BeginBlock, [DeliverTx, …], EndBlock, Commit。
• c.query链接：查询应用状态。
  
  mempool和Consensus Logic作为客户端，和应用（ABCI 服务器端）间维护一个open ABCI，上图展示了链接请求和响应类型 。

区块链百花争鸣的时代， 各种应用场景争相开放，就算在同一个领域，也会有各种产品出现。如分布式存储领域， 有storj, maidsafe, swarm, zeronet, ipfs等。在这里， 主角当然是IPFS。
正如比特币一样， 它没有产生新的技术，而是总结前人的技术， 它是p2p, 密码学，共识学等技术的组合体。IPFS则组合了4大技术点如下：

• 1.分布式哈希算法(kad算法，coral dsht算法，s/kad 算法）(快速点对点定位，最优路经，防攻击。)
• 2.百度种子用到的技术BitTorrent(数据是双通道传输，参与人越多速度越快，解决了带宽问题。)
• 3.分布式版本控制系统git(分布式记录所有版本，安全的有据可查。)
• 4.自我认证文件系统-SFS(分布式信任链，平等共享的全局命名空间。方便所有的文件有全局唯一名字)
  IPFS是位于TCP/IP协议的应用层协议（与http协议是竞争关系）。www虽然带来了一次互联网革命，但http协议设计的很丑陋， 所有的事情都集中在一段报文中。
  
  http需要中心化的域名服务器，更需要中心化的web服务器。对于重要网站，必须要花费大量的成本防DDOS攻击， 也需要时刻担心服务器数据丢失。
  
  IPFS协议栈是漂亮的, 是对现有臃肿的http协议的一次革命。看下图：
  
  IPFS 技术栈
• 1.sfs，git技术分别用到了IPNS 层，应用层(applications)。 全局唯一名字, 带版本跟踪。
• 2.BitTorrent, 分布式哈希算法分别用到了数据交换层(exchange)，路由层(routing)。快速定位，省带宽交换。
  IPFS与http相比，瘦客户，富协议，解决了http应用的复杂编程。再加上解决了上面指出的http缺点， 这是对http的革命。以前的web等应用面对瓶颈，都是改良http，然而导致应用很胖。既然IPFS是革命http，革命，是需要流血的。撼动能满足现在的http协议不容易， 所以IPFS需要寻找革命的战友， 它提出来了用区块链来作为革命的导火索。为了应用区块链，最需搬走的大山是共识问题。目前为止，得到世人验证的有效防拜占庭共识只有POW。而IPFS想发布基于POR(带激励机制的带宽，存储容量等资源相关的一种共识)的filecoin，这无疑是困难的。所以这也是，持续这么久， IPFS都没出正式版白皮书的原因。因为区块链很火，应用都往区块链上靠，但要成为区块链应用，必须要解决共识问题。IPFS也不例外，IPFS的最难点， 就是怎么解决POR的共识问题，开发者还没有发布最实际的有效做法。个人看法， 如果IPFS能完美的解决POR问题， www的今天，就是IPFS的明天。

雷电网络

基于以太坊的快速数字资产交易

以太坊上网络支付通道
Raiden 利用链下网络状态技术给以太坊上的数字资产带来了许多nice的属性：

• 1.可扩展性: 它与参与者的数量呈线性关系（每秒可能有1,000,000+次转帐)。
• 2.快速： 转账在一秒钟的时间内被确认和确定。
• 3.匿名性：单次转帐不会显示在全局分布式帐本中。
• 4.互操作性： 以太坊上任何实现了标准代币的接口的代币都可以互相交易。
• 5.低额交易费： 交易费比区块链上的交易费低7个数量级。
• 6.小额支付： 低交易费允许有效的转移小额资金。
  技术点
  该技术类似于比特币的闪电网络。
  基本思想是： 所有的交易需要记载到区块链上的共享账本上（这是区块链的瓶颈），而该技术是通过交易双方私下签名交易信息， 不需要全部上链。Raiden 使用一个p2p支付通道网络，并在以太坊的区块链上存一定的押金。Raiden 是以太坊上的一个扩展应用。Raiden 节点和以太坊的节点互相联通工作，作为交易的基础设施， 并用以太坊上的链来管理通道的存证信息。Raiden 提供了简单的API, 使得DApps 非常容易实现。
  应用
• 为内容分发做小额计费：Paywalls,广告和订阅。
• 去中心化的M2M市场： 特别是在物联网中， 微小的带宽， 存储， cpu占有率， 能量， 传感器数据等可以交易。
• 没有交集的代币系统： 游戏代币， 奖励代币， 私有货币。
• API 访问： 对于即将来临的M2M经济，每次API 访问计费。
• 快速去中心话交易。
  与以太坊相辅相成
  Vitalik Buterin 说：“ 状态通道是一种重要技术， 有可能大大提高许多区块链应用程序的可扩展性和隐私性； 结合分片和其他隐私秘密保护技术， 他们是一个重要的组合，可以实现去中心化的许多属性，而这些属性是圈内人和机构所期望，也应该实现的“

Raiden 1.0 详解：
Raiden 1.0 通过合约的方式实现了token 的线下状态通道支付。
Registry 合约是系统注册合约，以太坊上的每一种代币都可以一次注册， 然后会产生一个基于该token的状态通道管理合约。每个有该token的用户都可以选择一个搭档建立一个状态通道合约，通过设置押金（会在链上存证）实现线下通道支付，线下交易都是双方各自签名确认即可， 撤出时， 再双方提供证据， 链上交易存证。合约如下：

Raiden 的类介绍：

Asset

• a. 没有特殊规范来规定哪样的资产。
• b.只要是上链的一个简单合约地址就可以（如Toke address）。

  RaidenProtocol

• a.节点间的传输层交互
• b.RaidenService 的网络事件通知。

  Raiden Service

• a.链下运行。
• b.Raiden 的根类。
• c.暴露Raiden 与Raiden的接口。
• d.需要直接访问本地的Blockchain节点。
• e.管理所有的链上链下交互路由。
• f.维护AssetManagers列表。
• g.每个维护的AssetManagers只负责一个资产。

  AssetManager

• a.链下运行。
• b.完全由RaidenService实例拥有。
• c.与一个单一资产相关联。
• d.与链上的ChannelManagerContract相关联，负责同一个资产。
• e.在单一资产上维护一组到其他节点的通道。
• f.从链上的ChannelManagerContract获取通道初始化列表。

  ChannelManagerContract

• a.链上运行。
• b.关联实实在在的一种资产。
• c. 维护链上的NettingChannelContracts列表。

  NettingChannelContract

• a.链上运行。
• b.和一种资产相关联。
• c.知道同一通道的两个参与方(链上 地址）
• d.持有双方存款
• e.在链上执行一个通道的结算。

  TransferManager

• a.链下运行。
• b.负责处理TransferTasks，它们代表了脱机通道中双方之间的单一转移。
• c.在没有直接目标通道打开的情况下，会产生TransferTask 作为中介转移。
• d.如果具有接收到的转移目标的通道打开，则可以启动到目标的转移。

  TransferTask(UML: transfer_activity, transfer_state)

• a.链下运行。
• b.异步运行， 通过网络事件触发。
• c.和AssetManager, TransferManager 和RaidenService 相关联。
• d. 和transfer完全相关联。
• e.负责找到与之相关联的传输路径。
• i. 路径是活跃的。
• ii.路径有足够的资金用于转移。
• f.如果找不到路径，则启动CancelTransfer。

  Transfer

• a.包含nonce, 资产, 金额，参与方，locksroot[, secret]。
• b. nonce: 跟踪消息序列的计数器。Transfers的nonce 在通道中更新, 参与方的nonce在参与方的本地镜像中更新。
• c.是一个merkle树的树根。它记录了他们的hashlocks的最精简locked_ammounts。

  LockedTransfer

• a. 如果收款人知道hashlock的secret, 那么他就可以声明locked_amount。 locked_amount不是余额的一部分，而是在locksroot中隐含。

  Channel

• a.链下运行。
• b.被本地或者伙伴节点初始化。
• c.在链上有一个相对应的NettingChannelContract。
• d.在每个资产的对端节点中最多有一个通道。也就是说，（目前）最多两个(不同的)节点可以为每个资产设置一个通道。
• e.和伙伴节点维护最终的交易账本。
• f.执行创造和取消transfers。
• g.维护LockedTransfers列表。
• h. 执行LockedTransfers的声明。
• i.更新自己和伙伴的账目（接受或者发送）。

  各模块关系图如下：

  

  核心步骤。

  Transfers in a channel

• a.类型: Transfer, LockedTransfer (Parent class for): MediatedTransfer, CancelTransfer。
• b.Trasfers 接收到一个RaidenProtocol实例化的消息，并转发给RaidenService,由TransferManager来真正的处理。
• c.TransferManager 从AssetManager中获得相关联的通道。
• d.任何通道可以追踪Transfers和LockedTransfers。
• e.Transfers 可以通过通道发送给参与方的节点， 也可以注册本地通道。因此，通道中的transfer既可以是用于发送的， 也可以是用于接收的。
• f.一旦接收到transfer, 由通道注册。
• i.Transfer 接收者必须要有正确的nonce。这个nonce是当每次接收到伙伴节点transfer而增加。这个nonce 在本地伙伴节点维护。参与双方维护相同的增加。保证参与transfer双方的序列一致性。
• ii.收到的transfer包含secret, 解锁secret得到金额, 并相应更新余额。
• iii.如果我们收到了LockerTransfer，LockedTransfer将被注册。
• iiii.最后，自己的余额和合作伙伴的余额根据allowance（= transfer.balance - self.balance）进行更新。如果转让包含secreted, 余额则根据步骤ii中触发的声明进行。
• g.如果Transfer被发送， 则由Channel注册：
• i.对于接收方，是对称的。
• ii.我们不需要验证lockroots是否正确。
• h.只有节点的当前余额超过传送的额度并且未达到到期的块高度(后者仅与LockedTransfers相关)，Transfers才能被初始化。

选择多条Transfer的场景

正常的Transfer

1
2
3
4
5
6
7

A 通过B 转帐给C：
A： 初始化secret
A： MediatedTransfer -> B
B：MediatedTransfer ->  C
C：secretRequest -> A (证明收到的transfer是有效的)
A：Secret -> C
C：Secret -> B

CancelTransfer:

1
2
3
4
5
6

A： 初始化Secret
A： MediatedTransfer -> B
B： MediatedTransfer -> C(失败： C 不能和D建立路经)
C：CancelTransfer -> B
B：MediatedTransfer -> C2
C2：MediatedTransfer -> D

TimeoutTransfer

1
2
3
4
5

A： 初始化Secret
B： MediatedTransfer -> B
B： MediatedTransfer -> C (失败：没有接收到C的ACK消息)
B: TransferTimeout -> A
决议：A不会透露secret，尝试新的transfer，B禁止C

私有链上运行步骤：（geth 需要 < 1.6.0的版本）

1，编译合约，并生成到genesis.json。

1

python tools/config_builder.py full_genesis > mycustomgenesis.json

2， 根据genesis.json初始化内容到指定目录。

1

geth --datadir /tmp/privategeth init mycustomgenesis.json

3，启动geth

1

geth --datadir /tmp/privategeth --networkid 123 --nodiscover --maxpeers 0 --rpc --minerthreads 1 --etherbase c13f2e8e9c92d81de806023d68cc64fe85bf6740 --mine

4，启动雷电网络

1

raiden --eth_rpc_endpoint 127.0.0.1:8545 --registry_contract_address 79eafd0b5ec8d3f945e6bb2817ed90b046c0d0af --discovery_contract_address 2ce636d6240f8955d085a896e12429f8b3c7db26

进入Raiden 控制台

举一个 alice 给 bob 转帐的例子：

• 1.创建token, 或者用已有toke

  1	token_address = tools.create_token(initial_alloc=1000, name="mytoken", symbol="MT", decimals=2)

• 2.Bob的地址

  1	bob = 'addresss of partner without leading 0x'

• 3.确保可以链接bob

  1	tools.ping(bob)

• 4.打开状态通道

  1	tools.open_channel_with_funding(token_address, bob, amount)

• 5.bob的操作

  1	raiden.api.deposit(token_address, alice, amount)

• 6.可以互相转帐

  1 2 3 4

  alice -> bob raiden.api.transfer(token_address, 73, bob) bob -> alice raiden.api.transfer(token_address, 50, alice)

• 7.可以查看通道的状态

  1	tools.channel_stats_for(token_address, bob, pretty=True)

• 8.关闭通道

  1	raiden.api.close(token_address, bob)

• 9.为了防止对方欺骗，设置了settle过程，有10个块的timeout, 等待对方确认

  1	raiden.api.settle(token_address, bob)

• 10.可以查看双方的资金状况：

  1 2	asset.balance_of(raiden.address) asset.balance_of(bob)

Raiden 2.0 正在准备实现側链的功能。

IPFS - 可快速索引的版本化的点对点文件系统（草稿3）

作者： Juan Benet (juan@benet.ai)
译者： 郭光华(gavin@8btc.com)

摘要

星际文件系统是一种点对点的分布式文件系统， 旨在连接所有有相同的文件系统的计算机设备。在某些方面， IPFS类似于web, 但web 是中心化的，而IPFS是一个单一的Bittorrent 群集， 用git 仓库分布式存储。换句话说， IPFS 提供了高吞吐量的内容寻址块存储模型， 具有内容寻址的超链接。这形成了一个广义的Merkle DAG 数据结构，可以用这个数据结构构建版本文件系统，区块链，甚至是永久性网站。。IPFS 结合了分布式哈希表， 带有激励机制的块交换和自我认证命名空间。IPFS 没有单故障点， 节点不需要相互信任。

1. 介绍

在全球分布式文件系统这领域， 已经有许多人的尝试。一些系统已经取得了重大的成功， 而很多却完全失败了。在学术尝试中， AFS【6】就是成功的例子，如今已经得到广泛的应用， 然而，其他的【7， ？】却没有得到相同的结果。在学术界之外，应用最广泛的是面向音视频媒体的点对点文件共享系统。 最值得注意的是， Napster, KaZaA 和BitTorrent[2]部署的文件分发系统支持1亿用户的同时在线。即使在今天， BitTorrent 也维持着每天千万节点的活跃数。 基于这些学术文件系统理论而实现的应用程序有很多的用户量， 然而，这些系统理论是在应用层，而没有放在基础层。以致没有出现通用的文件系统基础框架， 给全球提供低延迟的分发。
也许是因为HTTP这样“足够好“的系统已经存在。到目前为止，HTTP已经作为“分布式文件系统“的协议，并且已经大量部署，再与浏览器相结合，具有巨大的技术和社会影响力。在现在， 它已经成为互联网传输文件的事实标准。然而，他没有采用最近15年的发明的数十种先进的文件分发技术。 从一方面讲， 由于向后兼容的限制 和 当前新模式的投入， 不断发展http web 的基础设施几乎是不可能的。但从一个角度看， 从http 出现以来， 已经有许多新协议出现并被广泛使用。升级http协议虽然能引入新功能和加强当前http协议，但会降低用户的体验。
有些行业已经摆脱使用HTTP 这么久， 因为移动小文件相对便宜，即使对拥有大流量的小组织也是如此。但是，随着新的挑战，我们正在进入数据分发的新纪元。

• （a）托管和分发PB级数据集，
• （b）跨组织的大数据计算，
• （c）大批量的高清晰度按需或实时媒体流，
• （d）大规模数据集的版本化和链接，
• （e）防止意外丢失重要文件等。其中许多可以归结为“大量数据，无处不在”。由于关键功能和带宽问题，我们已经为不同的数据放弃了HTTP 分销协议。下一步是使它们成为web自己的一部分。
  正交于有效的数据分发，版本控制系统，已经设法开发重要的数据协作工作流程。Git是分布式源代码版本控制系统，开发了许多有用的方法来建模和实现分布式数据操作。Git工具链提供了灵活的版本控制功能，这正是大量的文件分发系统所严重缺乏的。由Git启发的新解决方案正在出现，如Camlistore [？]，个人文件存储系统，Dat [？]数据协作工具链和数据集包管理器。Git已经影响了分布式文件系统设计[9]，因为其内容涉及到Merkle DAG数据模型，能够实现强大的文件分发策略。还有待探讨的是，这种数据结构如何影响面向高吞吐量的文件系统的设计，以及如何升级Web本身。
  本文介绍了IPFS，一种新颖的对等版本控制的文件系统，旨在调和这些问题。 IPFS综合了许多以前成功的系统的优点。 IPFS产生了突出的效果， 甚至比参考的这些系统的总和还要好。IPFS的核心原则是将所有数据建模为同一Merkle DAG的一部分。

  2. 背景

  本节回顾了IPFS所采用成功的点对点系统技术的重要属性。

  2.1 分布式哈希表(DHT)

  分布式散列表（DHT）被广泛用于协调和维护关于对等系统的元数据。比如，MainlineDHT 是一个去中心化哈希表，他可追踪查找所有的对等节点。

  2.1.1 Kademlia DHT

  Kademlia[10] 是受欢迎的DHT, 它提供：
• 1.通过大量网络进行高效查询：查询平均联系人O(log2N)节点。 （例如，20跳10万个节点的网络）
• 2.低协调开销：优化数量的控制消息发送到其他节点。
• 3.抵抗各种攻击，喜欢长寿节点。
• 4.在对等应用中广泛使用，包括Gnutella和BitTorrent，形成了超过2000万个节点的网络[16]。

2.1.2 Coral DSHT

虽然一些对等文件系统直接在DHT中存储数据块，这种“数据存储在不需要的节点会乱费存储和带宽”[5]。Coral DSHT扩展了Kademlia三个特别重要的方式：

• 1.Kademlia在ids为“最近”（使用XOR-distance）的关键节点中存储值。这不考 虑应用程序数据的局部性，忽略“远”可能已经拥有数据的节点，并强制“最近”节点存储它，无论它们是否需要。这浪费了大量的存储和带宽。相反，Coral 存储了地址， 该地址的对等节点可以提供相应的数据块。
• 2.Coral将DHT API从get_value(key)换成了get_any_values(key)（DSHT中的“sloppy”）中。这仍然是因为Coral用户只需要一个（工作）的对等体，而不是完整的列表。作为回报，Coral可以仅将子集分配到“最近”的节点，避免热点（当密钥变得流行时，重载所有最近的节点）。
• 3.另外，Coral根据区域和大小组织了一个称为群集的独立DSHT层次结构。这使得节点首先查询其区域中的对等体，“查找附近的数据而不查询远程节点”[5]并大大减少查找的延迟。

  2.1.3 S/Kademlia DHT

  S/Kademlia[1] 扩展了Kademlia, 用于防止恶意的攻击。有如下两方面的方法：
• 1.S/Kad 提供了方案来保证NodeId的生成已经防止Sybill攻击。它需要节点产生PKI公私钥对。从中导出他们的身份，并彼此间签名。一个方案使用POW工作量证明，使得生成Sybills成本高昂。
• 2.S/Kad 节点在不相交的路径上查找直， 即使网络中存在大量的不诚实节点，也能确保诚实节点可以互相链接。即使网络中存在一半的不诚实节点，S/Kad 也能达到85%的成功率。

  2.2 块交换 - BitTorrent

  BitTorrent[3] 是一个广泛成功应用的点对点共享文件系统，它可以在存在不信任的对等节点（群集）的协作网络中分发各自的文件数据片。从BitTorrent和它的生态系统的关键特征， IPFS得到启示如下：
• 1.BitTorrent的数据交换协议使用了一种bit-for-tat的激励策略， 可以奖励对其他方面做贡献的节点，惩罚只榨取对方资源的节点。
• 2.BitTorrent对等体跟踪文件的可用性，优先发送稀有片段。这减轻了seeds节点的负担， 让non-seeds节点有能力互相交易。
• 3.对于一些剥削带宽共享策略， BitTorrent的标准tit-for-tat策略是非常脆弱的。 然而，PropShare[8]是一种不同的对等带宽分配策略， 可以更好的抵制剥削战略， 提高群集的表现。

  2.3. 版本控制系统- Git

  版本控制系统提供了对随时间变化的文件进行建模的设施，并有效地分发不同的版本。流行版本控制系统Git提供了强大的Merkle DAG对象模型，以分布式友好的方式捕获对文件系统树的更改。
• 1.不可更改的对象表示文件（blob），目录（树）和更改（提交）。
• 2.通过加密hash对象的内容，让对象可寻址。
• 3.链接到其他对象是嵌入的，形成一个Merkle DAG。这提供了很多有用的完整和work-flow属性。
• 4.很多版本元数据（分支，标示等等）都只是指针引用，因此创建和更新的代价都小。
• 5.版本改变只是更新引用或者添加对象。

• 6.分布式版本改变对其他用户而言只是转移对象和更新远程引用。

  2.4 自我认证认文件系统-SFS

  SFS [ 12，11 ]提出了两个引人注目的实现（a）分布式信任链，和（b）平等共享的全局命名空间。SFS引入了一种自我建构技术—注册文件：寻址远程文件系统使用以下格式：

  1 2 3

  /sfs/<Location>:<HostID> Location:代表的是服务网络地方 HostID = hash(public_key || Location)

  因此SFS文件系统的名字认证了它的服务，用户可以通过服务提供的公钥来验证，协商一个共享的私钥，保证所有的通信。所有的SFS实例都共享了一个全局的命名空间，这个命名空间的名称分配是加密的，不被任何中心化的body控制。

3. IPFS设计

IPFS是一个分布式文件系统，它综合了以前的对等系统的成功想法，包括DHT，BitTorrent，Git和SFS。 IPFS的贡献是简化，发展和将成熟的技术连接成一个单一的内聚系统，大于其部分的总和。 IPFS提供了编写和部署应用程序的新平台，以及一个新的分发系统版本化大数据。 IPFS甚至可以演进网络本身。
IPFS是点对点的;没有节点是特权的。 IPFS节点将IPFS对象存储在本地存储中。节点彼此连接并传输对象。这些对象表示文件和其他数据结构。 IPFS协议分为一组负责不同功能的子协议：
1. 身份 - 管理节点身份生成和验证。描述在3.1节。
2.网络 - 管理与其他对等体的连接，使用各种底层网络协议。可配置的。详见3.2节。
3.路由 - 维护信息以定位特定的对等体和对象。响应本地和远程查询。默认为DH​​T，但可更换。在3.3节描述。
4.交换 - 一种支持有效块分配的新型块交换协议（BitSwap）。模拟市场，弱化数据复制。贸易策略可替换。描述在3.4节。
5.对象 - 具有链接的内容寻址不可更改对象的Merkle DAG。用于表示任意数据结构，例如文件层次和通信系统。详见第3.5节。
6.文件 - 由Git启发的版本化文件系统层次结构。详见3.6节。
7.命名 - 自我认证的可变名称系统。详见3.7节。
这些子系统不是独立的;它们是集成在一起，互相利用各自的属性。但是，分开描述它们是有用的，从下到上构建协议栈。符号：Go语言中指定了以下数据结构和功能

3.1 身份

节点由NodeId标识，这是使用S / Kademlia的静态加密难题[1]创建的公钥的密码散列。节点存储其公私钥（用密码加密）。用户可以在每次启动时自由地设置一个“新”节点身份，尽管这会损失积累的网络利益。激励节点保持不变。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

         type NodeId Multihash
         type Multihash []byte  // 自描述加密哈希摘要
         type PublicKey []byte
         type PrivateKey []byte // 自描述的私钥
         type Node struct {
             NodeId NodeID
             PubKey PublicKey
             PriKey PrivateKey
         }
基于S / Kademlia的IPFS身份生成：
        difficulty = <integer parameter>
        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)

首次连接时，对等体交换公钥，并检查：hash（other.PublicKey）等于other.NodeId。如果没有，则连接被终止
关于加密函数的注意事项：
IPFS不是将系统锁定到一组特定的功能选择，而是支持自我描述的值。哈希摘要值以多重哈希格式存储，其包括指定使用的哈希函数的头和以字节为单位的摘要长度。例如：

1

<function code><digest length><digest bytes>

这允许系统

• （a）选择最佳功能用例（例如，更强的安全性与更快的性能），
• （b）随着功能选择的变化而演变。自描述值允许兼容使用不同的参数选择。

  3.2 网络

  IPFS节点与数百个其他节点进行定期通信网络中的节点，可能跨越广域网络。IPFS网络堆栈功能：
• 传输层： IPFS可以使用任何传输协议，并且最适合WebRTC DataChannels [？]（用于浏览器连接）或uTP（LEDBAT [14]）。
• 可靠性： 如果底层网络不提供可靠性，IPFS可使用uTP（LEDBAT [14]）或SCTP [15]来提供​​可靠性。
• 可连接性：IPFS还可以使用ICE NAT穿墙打洞技术[13]。
• 完整性：可以使用哈希校验和来检查邮件的完整性。
• 可验证性：可以使用发送者的公钥使用HMAC来检查消息的真实性。

  3.2.1对等节点寻址注意事项：

  IPFS可以使用任何网络; 但它不承担对IP的获取以及不直接依赖于ip层。这允许在覆盖网络中使用IPFS。
  IPFS将地址存储为多层地址，这个多层地址是由字节字符串组成的， 以便于给底层网络使用。多层地址提供了一种方式来表示地址及其协议，可以封装成好解析的格式。例如：

  1 2 3 4

  # an SCTP/IPv4 connection /ip4/10.20.30.40/sctp/1234/ # an SCTP/IPv4 connection proxied over TCP/IPv4 /ip4/5.6.7.8/tcp/5678/ip4/1.2.3.4/sctp/1234/

3.3 路由

IPFS节点需要一个路由系统， 这个路由系统可用于查找：

• （a）其他同伴的网络地址，
• （b）专门用于服务特定对象的对等节点。
  IPFS使用基于S / Kademlia和Coral的DSHT，在2.1节中具体介绍过。在对象大小和使用模式方面， IPFS 类似于Coral[5] 和Mainline[16], 因此，IPFS DHT根据其大小对存储的值进行区分。小的值（等于或小于1KB）直接存储在DHT上。对于更大的值，DHT只存储值索引，这个索引就是一个对等节点的NodeId, 该对等节点可以提供對该类型的值的具体服务。
  DSHT的接口如下：

  1 2 3 4 5 6 7

  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) // 获取服务于该大数据的节点。 }

注意：不同的用例将要求基本不同的路由系统（例如广域网中使用DHT，局域网中使用静态HT）。因此，IPFS路由系统可以根据用户的需求替换的。只要使用上面的接口就可以了，系统都能继续正常运行。

3.4块交换 - BitSwap协议

IPFS 中的BitSwap协议受到BitTorrent 的启发，通过对等节点间交换数据块来分发数据的。像BT一样， 每个对等节点在下载的同时不断向其他对等节点上传已下载的数据。和BT协议不同的是， BitSwap 不局限于一个torrent文件中的数据块。BitSwap 协议中存在一个永久的市场。 这个市场包括各个节点想要获取的所有块数据。而不管这些块是哪些如.torrent文件中的一部分。这些快数据可能来自文件系统中完全不相关的文件。 这个市场是由所有的节点组成的。
虽然易货系统的概念意味着可以创建虚拟货币，但这将需要一个全局分类账本来跟踪货币的所有权和转移。这可以实施为BitSwap策略，并将在未来的论文中探讨。
在基本情况下，BitSwap节点必须以块的形式彼此提供直接的值。只有当跨节点的块的分布是互补的时候，各取所需的时候，这才会工作的很好。 通常情况并非如此，在某些情况下，节点必须为自己的块而工作。 在节点没有其对等节点所需的（或根本没有的）情况下，它会更低的优先级去寻找对等节点想要的块。这会激励节点去缓存和传播稀有片段， 即使节点对这些片段不感兴趣。

3.4.1 - BitSwap 信用

这个协议必须带有激励机制， 去激励节点去seed 其他节点所需要的块，而它们本身是不需要这些块的。 因此， BitSwap的节点很积极去给对端节点发送块，期待获得报酬。但必须防止水蛭攻击（空负载节点从不共享块），一个简单的类似信用的系统解决了这些问题：

• 1， 对等节点间会追踪他们的平衡（通过字节认证的方式）。
• 2， 随着债务增加而概率降低，对等者概率的向债务人发送块。
  注意的是，如果节点决定不发送到对等体，节点随后忽略对等体的ignore_cooldown超时。 这样可以防止发送者尝试多次发送（洪水攻击） （BitSwap默认是10秒）。

  3.4.2 BitSwap的策略

  BitSwap 对等节点采用很多不同的策略，这些策略对整个数据块的交换执行力产生了不同的巨大影响。在BT 中， 标准策略是明确规定的（tit-for-tat），其他不同的策略也已经被实施，从BitTyrant [8]（尽可能分享）到BitThief [8]（利用一个漏洞，从不共享），到PropShare [8]（按比例分享）。BitSwap 对等体可以类似地实现一系列的策略（良好和恶意）。对于功能的选择，应该瞄准：
• 1.为整个交易和节点最大化交易能力。
• 2.为了防止空负载节点利用和损害交易。
• 3.高效抵制未知策略。
• 4.对可信任的对等节点更宽容。
  探索这些策略的空白是未来的事情。在实践中使用的一个选择性功能是sigmoid，根据负债比例进行缩放：
  让负债比例在一个节点和它对等节点之间：

  1	r = bytes_sent / bytes_recv + 1

根据r，发送到负债节点的概率为：

1

P(send | r ) = 1 − ( 1/  ( 1 + exp(6 − 3r) ) )

正如你看到的图片1，当节点负债比例超过节点已建立信贷的两倍，发送到负债节点的概率就会急速下降。

图片1  当r增加时发送的概率

负债比是信任的衡量标准：对于之前成功的互换过很多数据的节点会宽容债务，而对不信任不了解的节点会严格很多。这个(a)给与那些创造很多节点的攻击者（sybill 攻击）一个障碍。(b)保护了之前成功交易节点之间的关系，即使这个节点暂时无法提供数据。(c)最终阻塞那些关系已经恶化的节点之间的通信，直到他们被再次证明。

3.4.3 BitSwap 账本

BitSwap节点保存了一个记录与所有其他节点之间交易的账本。这个可以让节点追踪历史记录以及避免被篡改。当激活了一个链接，BitSwap节点就会互换它们账本信息。如果这些账本信息并不完全相同，分类账本将会重新初始化， 那些应计信贷和债务会丢失。 恶意节点会有意去失去“这些“账本， 从而期望清除自己的债务。节点是不太可能在失去了应计信托的情况下还能累积足够的债务去授权认证。伙伴节点可以自由的将其视为不当行为， 拒绝交易。

1
2
3
4
5
6
7

 type Ledger struct {
    owner NodeId
    partner NodeId
    bytes_sent int
    bytes_recv int
    timestamp Timestamp
}

节点可以自由的保留分布式账本历史，这不需要正确的操作，因为只有当前的分类账本条目是有用的。节点也可以根据需要自由收集分布式帐本，从不太有用的分布式帐开始：老（其他对等节点可能不存在）和小。

3.4.4 BitSwap 详解

BitSwap 节点有以下简单的协议。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

// Additional state kept
  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);
}

对等连接的生命周期草图：

• 1.Open: 对等节点间发送ledgers 直到他们同意。
• 2.Sending: 对等节点间交换want_lists 和blocks。
• 3.Close: 对等节点断开链接。
• 4.Ignored: （特殊）对等体被忽略（等待时间的超时）如果节点采用防止发送策略。
  Peer.open(NodeId, Ledger).
  当发生链接的时候，节点会初始化链接的账本，要么保存一个份链接过去的账本，要么创建一个新的被清零的账本。然后，发送一个携带账本的open信息给对等节点。
  接收到一个open信息之后，对等节点可以选择是否接受此链接。如果，根据接收者的账本，发送者是一个不可信的代理（传输低于零或者有很大的未偿还的债务），接收者可能会选择忽略这个请求。忽略请求是ignore_cooldown超时来概率性实现的，为了让错误能够有时间改正和攻击者被挫败。
  如果链接成功，接收者用本地账本来初始化一个Peer对象以及设置last_seen时间戳。然后，它会将接受到的账本与自己的账本进行比较。如果两个账本完全一样，那么这个链接就被Open，如果账本并不完全一致，那么此节点会创建一个新的被清零的账本并且会发送此账本。
  Peer.send_want_list(WantList)
  当链接已经Open的时候，节点会广发它们的want_list给所有已经链接的对等节点。这个是在(a)open链接后(b)随机间歇超时后(c)want_list改变后(d)接收到一个新的块之后完成的。
  当接收到一个want_list之后，节点会存储它。然后，会检查自己是否拥有任何它想要的块。如果有，会根据上面提到的BitSwap策略来将want_list所需要的块发送出去。
  Peer.send_block(Block)
  发送一个块是直接了当的。节点只是传输数据块。当接收到了所有数据的时候，接收者会计算多重hash校验和来验证它是否是自己所需数据，然后发送确认信息。
  在完成一个正确的块传输之后，接受者会将此块从need_list一到have_list,最后接收者和发送者都会更新它们的账本来反映出传输的额外数据字节数。
  如果一个传输验证失败了，发送者要么会出故障要么会攻击接收者，接收者可以选择拒绝后面的交易。注意，BitSwap是期望能够在一个可靠的传输通道上进行操作的，所以传输错误（可能会引起一个对诚实发送者错误的惩罚）是期望在数据发送给BitSwap之前能够被捕捉到。
  Peer.close(Bool)
  传给close最后的一个参数，代表close链接是否是发送者的意愿。如果参数值为false,接收者可能会立即重新open链接，这避免链过早的close链接。
  一个对等节点close链接发生在下面两种情况下：
• silence_wait超时已经过期，并且没有接收到来自于对等节点的任何信息（BitSwap默认使用30秒），节点会发送Peer.close(false)。
• 在节点退出和BitSwap关闭的时候，节点会发送Peer.close(true).
  接收到close消息之后，接收者和发送者会断开链接，清除所有被存储的状态。账本可能会被保存下来为了以后的便利，当然，只有在被认为账本以后会有用时才会被保存下来。
  注意点：
  非open信息在一个不活跃的连接上应该是被忽略的。在发送send_block信息时，接收者应该检查这个块，看它是否是自己所需的，并且是否是正确的，如果是，就使用此块。总之，所有不规则的信息都会让接收者触发一个close(false)信息并且强制性的重初始化此链接。

  3.5 Merkle DAG对象

  DHT和BitSwap允许IPFS构造一个庞大的点对点系统用来快速稳定的分发和存储。最主要的是，IPFS建造了一个Merkle DAG,一个无回路有向图，对象之间的links都是hash加密嵌入在源目标中。这是Git数据结构的一种推广。Merkle DAGS给IPFS提供了很多有用的属性，包括：
• 1.内容可寻址：所有内容都是被多重hash校验和来唯一识别的，包括links。
• 2.防止篡改：所有的内容都用它的校验和来验证。如果数据被篡改或损坏，IPFS会检测到。
• 3.重复数据删除：所有的对象都拥有相同的内容并只存储一次。这对于索引对象非常有用，比如git的tree和commits，或者数据的公共部分。

IPFS对象的格式是：

1
2
3
4
5
6
7
8
9
10

  type IPFSLink struct {
        Name string      // 此link的别名
        Hash Multihash // 目标的加密hash
        Size int             // 目标总大小
  }
type IPFSObject struct {
      links []IPFSLink   //links数组
      data []byte         //不透明内容数据
}

IPFS Merkle DAG是存储数据非常灵活的一种方式。只要求对象引用是(a）内容可寻址的，(b)用上面的格式编码。IPFS允许应用完全的掌控数据域；应用可以使用任何自定义格式的数据，即使数据IPFS都无法理解。单独的内部对象link表允许IPFS做：

• 用对象的形式列出所有对象引用，例如：

  1 2 3 4 5 6

  > ipfs ls /XLZ1625Jjn7SubMDgEyeaynFuR84ginqvzb XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x 189458 less XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5 19441 script XLF4hwVHsVuZ78FZK6fozf8Jj9WEURMbCX4 5286 template <object multihash> <object size> <link name>

• 解决字符串路经查找，例如foo/bar/baz。给出一个对象，IPFS会解析第一个路经成分进行hash放入到对象的link表中，再获取路径的第二个组成部分，一直如此重复下去。因此，任何数据格式的字符串路经都可以在Merkle DAG中使用。
  *递归性的解决所有对象引用：

  1 2 3 4 5 6

  > ipfs refs --recursive \ /XLZ1625Jjn7SubMDgEyeaynFuR84ginqvzb XLLxhdgJcXzLbtsLRL1twCHA2NrURp4H38s XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5 XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z

原始数据结构公共link结构是IPFS构建任意数据结构的必要组成部分。可以很容易看出Git的对象模型是如何套用DAG的。一些其他潜在的数据结构：

• (a)键值存储
• (b)传统关系型数据
• (c)数据三倍存储
• (d) 文档发布系统
• (e)通信平台
• (f)加密货币区块。
  这些系统都可以套用IPFS Merkle DAG，这使这些系统更复杂的应用可以使用IPFS作为传输协议。

3.5.1 路经

IPFS对象可以遍历一个字符串路经。路经格式与传统UNIX文件系统以及Web一致。Merkle DAG的links使遍历变得很容易。全称路经在IPFS中的格式是：

1
2
3
4

*# 格式
/ipfs/<hash-of-object>/<name-path-to-object>
*# 例子
/ipfs/XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x/foo.txt

/ipfs前缀允许只要在挂载点不冲突(挂载点名称当然是可配置的)的情况下挂载到一个已存在的系统上。第二个路经组成部分(第一个是IPFS)是一个对象的hash。通常都是这种情况，因为没有全局的根。一个根对象可能会有一个不可能完成的任务，就是在分布式环境(可能还断开链接)中处理百万对象的一致性。因此，我们用地址可寻址来模拟根。通过的hash所有的对象都是可访问的。这意思是说，给一个路经对象/bar/baz，最后一个对象可以可以被所有的访问的：

1
2
3

/ipfs/<hash-of-foo>/bar/baz
/ipfs/<hash-of-bar>/baz
/ipfs/<hash-of-baz>

3.5.2 本地对象

IPFS客户端需要一个本地存储器，一个外部系统可以为IPFS管理的对象存储以及检索本地原始数据。存储器的类型根据节点使用案例不同而不同。在大多数情况下，这个存储器只是硬盘空间的一部分（不是被本地的文件系统使用键值存储如leveldb来管理，就是直接被IPFS客户端管理），在其他的情况下，例如非持久性缓存，存储器就是RAM的一部分。
最终，所有的块在IPFS中都是能够获取的到的，块都存储在了一些节点的本地存储器中。当用户请求一个对象时，这个对象会被查找到并下载下来存储到本地，至少也是暂时的存储在本地。这为一些可配置时间量提供了快速的查找。

3.5.3对象锁定

希望确保特定对象生存的节点可以锁定此对象。这保证此特定对象被保存在了节点的本地存储器上。也可以递归的进行锁定所有相关的派生对象。这使所有被指定的对象都保存在本地存储器上。这对长久保存文件特别有用，包括引用。这也同样让IPFS成为一个links是永久的Web，且对象可以确保其他被指定对象的生存。

3.5.4 发布对象

IPFS是全球分布的。它设计为允许成千上万的用户文件可以共同的存在的。DHT使用内容哈希寻址技术，使发布对象是公平的，安全的，完全分布式的。任何人都可以发布对象，只需要将对象的key加入到DHT中，并且以对象是对等节点的方式加入进去，然后把路径给其他的用户。要注意的是，对象本质上是不可改变的，就像在Git中一样。新版本的哈希值不同，因此是新对象。跟踪版本则是额外版本对象的工作。

3.5.5 对象级别的加密

IPFS是具备可以处理对象级别加密操作的。一个已加密的或者已签名的对象包装在一个特殊的框架里，此框架允许加密和验证原始字节。

1
2
3
4
5
6
7
8

type EncryptedObject struct {
	Object []bytes // 已加密的原始对象数据
	Tag []bytes    // 可选择的加密标识
	type SignedObject struct {
	Object []bytes  // 已签名的原始对象数据
	Signature []bytes // HMAC签名
	PublicKey []multihash // 多重哈希身份键值
}

加密操作改变了对象的哈希值，定义一个不同的新的对象。IPFS自动的验证签名以及使用用户指定的钥匙链解密数据。加密数据的links也同样的被保护着，没有解密秘钥就无法遍历对象。也存在着一种现象，可能父对象使用了一个秘钥进行了加密，而子对象使用了另一个秘钥进行加密或者根本没有加密。这可以保证links共享对象安全。

3.6 文件

IPFS在Merkle DAG上还为模型化版本文件系统定义了一组对象。这个对象模型与Git比较相似：
Block：一个可变大小的数据块
List：块或者其他链表的集合
Tree：块，链表，或者其他树的集合
Commit：树在版本历史记录中的一个快照
我原本希望使用与Git对象格式一致的模型，但那就必须要分开来引进在分布式文件系统中有用的某些特征，如

• (a)快速大小查找(总字节大小已经加入到对象中)
• (b)大文件的重复删除(添加到list对象)
• (c)commits嵌入到trees中。不过，IPFS文件对象与Git还是非常相近的，两者之间进行交流都是有可能的。而且，Git的一个系列的对象可以被引进过来转换都不会丢失任何的信息。（UNIX文件权限等等）。
  标记：下面的文件对象格式使用JSON。注意，虽然IPFS包含了JSON的互相转换，但是文件对象的结构体还是使用protobufs的二进制编码。

  3.6.1 文件对象：blob

  blob对象代表一个文件且包含一个可寻址的数据单元，IPFS的blobs就像Git的blobs或者文件系统数据块。它们存储用户的数据。需要留意的是IPFS文件可以使用lists或者blobs来表示。Blobs没有links。

  1 2 3

  { "data": "some data here", // blobs无links }

3.6.2 文件对象: list

List对象代表着由几个IPFS的blobs连接成的大文件或者重复数据删除文件。Lists包含着有序的blob序列或list对象。从某种程度上而言，IPFS的list函数就像一个间接块的文件系统。由于lists可以包含其他的lists，那么包含linked的链表和平衡树的拓扑结构是有可能的。有向图中相同的节点出现在多个不同地方允许在文件中重复数据删除。当然，循环是不可以能的，因为是被哈希寻址强制实行的。

1
2
3
4
5
6
7
8
9
10
11

{
"data": ["blob", "list", "blob"], //lists有一个对象类型的数组作为数据
"links": [
{ "hash": "XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x",
"size": 189458 },
{ "hash": "XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5",
"size": 19441 },
{ "hash": "XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z",
"size": 5286 } //在links中lists是没有名字的
]
}

3.6.3 文件对象：tree

IPFS中的tree对象与Git中相似，它代表着一个目录，一个名字到哈希值的映射。哈希值则表示着blobs，lists，其他的trees，或者commits。注意，传统路径的命名早已经被Merkle DAG实现了。

1
2
3
4
5
6
7
8
9
10
11

{
"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是有名字的
]
}

3.6.4 文件对象：commit

IPFS中的commit对象代表任何对象在版本历史记录中的一个快照。与Git中类似，但是它能够表示任何类型的对象。它同样link着发起对象。

3.6.5 版本控制

Commit对象代表着一个对象在历史版本中的一个特定快照。在两个不同的commit中比较对象（和子对象）可以揭露出两个不同版本文件系统的区别。只要commit和它所有子对象的引用是能够被访问的，所有前版本是可获取的，所有文件系统改变的全部历史是可访问的，这就与Merkle DAG对象模型脱离开来了。

Git版本控制工具的所有功能对于IPFS的用户是可用的。对象模型不完全一致，但也是可兼容的。这可能

• (a)构建一个Git工具版本改造成使用IPFS对象图，
• (b)构建一个挂载FUSE文件系统，挂载一个IPFS的tree作为Git的仓库，把Git文件系统的读/写转换为IPFS的格式。

  3.6.6 文件系统路径

  如我们在Merkle DAG中看到的一样，IPFS对象可以使用字符串路径API来遍历。IPFS文件对象是特意设计的，为了让挂载IPFS到UNIX文件系统更加简单。文件对象限制trees没有数据，为了使它们可以表示目录。Commits可以以代表目录的形式出现，也可以完全的隐藏在文件系统中。

3.6.7 将文件分隔成Lists和Blobs

版本控制和分发大文件其中一个最主要的挑战是：找到一个正确的方法来将它们分隔成独立的块。与其认为IPFS可以为每个不同类型的文件提供正确的分隔方法，不如说IPFS提供了以下的几个可选选择：
就像在LIBFS[?]中一样使用Rabin Fingerprints [?]来选择一个比较合适的块边界。
使用rsync[?] rolling-checksum算法，来检测块在版本之间的改变。
允许用户指定专为特定文件而调整的’快分隔’函数。

3.6.8路径查找性能

基于路径的访问需要遍历对象图。获取每个对象要求在DHT中查找它们的key，连接到对等节点，然后获取它的块。这造成相当大的开销，特别是查找的路径由很多子路径组成时。下面的方法可以减缓开销：

• tree缓存：由于所有的对象都是哈希寻址的，它们可以被无限的缓存。另外，trees一般比较小，所以比起blobs，IPFS会优先缓存trees。
• flattened trees：对于任何tree，一个特殊的 flattened tree可以构建一个链表，所有对象都可以从这个tree中访问得到。在flattened tree中名字就是一个从原始tree分离的路径，用斜线分隔。
  例如，对于上面的ttt111的flattened tree如下：

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

  { "data": ["tree", "blob", "tree", "list", "blob" "blob"], "links": [ { "hash": "<ttt222-hash>", "size": 1234 "name": "ttt222-name" }, { "hash": "<bbb111-hash>", "size": 123, "name": "ttt222-name/bbb111-name" }, { "hash": "<ttt333-hash>", "size": 3456, "name": "ttt333-name" }, { "hash": "<lll111-hash>", "size": 587, "name": "ttt333-name/lll111-name"}, { "hash": "<bbb222-hash>", "size": 22, "name": "ttt333-name/lll111-name/bbb222-name" }, { "hash": "<bbb222-hash>", "size": 22 "name": "bbb222-name" } ] }

3.7 IPNS：命名以及易变状态

目前为止，IPFS桟形成了一个对等块交换组成一个内容可寻址的DAG对象。这提供了发布和获取不可改变的对象。这甚至可以跟踪这些对象的版本历史记录。但是，这里有一个关键成分遗漏了：易变的命名。没有这个，发送IPFS的links，所有新内容的通信肯定都会有所偏差。现在所需就是能有某些方法可以获取相同路径的的易变状态。
这值得详述原因—如果最终易变数据是必须的—我们费了很大的力气构建了一个不可改变的Merkle DAG。就当做IPFS脱离了Merkle DAG的特征：对象可以

• (a)通过哈希值可以获取
• (b)完整性的检查
• (c)link其他的对象
• (d)无限缓存。从某种意义上说：
  对象就是永恒的
  这些就是一个高性能分布式系统的关键特征，在此系统上跨网络links之间移动文件是非常昂贵的。对象内容可寻址构建了一个具有以下特点的Web，(a)优秀的宽带优化(b)不受信任的内容服务(c)永恒的links(d)能够永久备任何对象以及它的引用。

不可变的内容可寻址对象和命名的Merkle DAG， 可变指针指向Merkle DAG，实例化了一个出现在很多成功分布式系统中的二分法。这些系统包括Git的版本控制系统，使用不可变的对象和可变的引用；还有UNIX分布式的继承者Plan9[?]文件系统，使用可变的Fossil和不可变的Venti[?]。LBFS[?]同样使用可变的索引以及不可变的块。

3.7.1 自我认证名称

使用SFS[12,11]中的命名方案，给我们提供了一个种可以构建自我认证名称的方法，
在一个加密指定的全局命名空间中，这是可变的。IPFS的方案如下：

• 1.回想一下在IPFS中：NodeId = hash(node.PubKey)
• 2.我们给每个用户分配一个可变的命名空间，在此路径下：/ipns/
• 3.一个用户可以在此路径下发布一个用自己私钥签名的对象，比如说：/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/
• 4.当其他用户获取对象时，他们可以检测签名是否与公钥和NodeId匹配。这个验证了用户发布对象的真实性，达到了可变状态的获取。

注意下面的细节：

• IPNS(InterPlanetary的命名空间)分开前缀是在可变和不可变的路径之间建立一个很容易辨认的区别，为了程序也为了人类阅读的便利。

• 因为这不是一个内容可寻址的对象，所以发布它就要依靠IPFS中的唯一的可变状态分配制度，路由系统。过程是(a)首先把此对象做一个常规的不可变IPFS的对象来发布(b)将此对象的哈希值作为元数据的值发布到路由系统上：

  1	routing.setValue(NodeId, <ns-object-hash>)

• 发布的对象中任何links在命令空间中充当子名称：

  1 2 3

  /ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/ /ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/docs /ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/docs/ipfs

• 一般建议发布一个commit对象或者其他对象的时候，要使用历史版本记录，因为这样就用户就可以找到之前使用过的名字。不过由于这并不总是需要的，所以留个用户自己选择。
  注意当用户发布一个对象的时候，他不能使用相同的方式来发布对象。

3.7.2人类友好名称

IPNS的确是一个分配和在分配名称的好方法，但是对用户却不是十分友好的，因为它使用很长的哈希值作为名称，众所周知这样的名称很难被记住。IPNS足够应付URLs，但对于很多线下的传输工作就没有这么好用了。因此，IPFS使用下面的技术来增加IPNS的用户友好度。
对等节点Links
被SFS所鼓舞，用户可以直接将其他用户的对象link到自己的对象上（命令空间，家目录等等）。这有一个好处就是创建了一个可信任的Web（也支持老的真实性认证模型）：

1
2
3
4
5
6
7
8

# Alice links 到Bob上
ipfs link /<alice-pk-hash>/friends/bob /<bob-pk-hash>
# Eve links 到Alice上
ipfs link /<eve-pk-hash/friends/alice /<alice-pk-hash>
# Eve 也可以访问Bob
/<eve-pk-hash/friends/alice/friends/bob
# 访问Verisign 认证域
/<verisign-pk-hash>/foo.com

DNS TXT IPNS 记录
如果/ipns/是一个有效的域名称，IPFS会在DNS TXT记录中查找关键的ipns。IPFS会将查找到的值翻译为一个对象的哈希值或者另一个ipns的路径：

1
2
3
4

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

Proquint 可读的标识符
总是会有将二进制编码翻译成可读文件的方法。IPNS则支持Proquint[?].。如下：

1
2
3
4

# proquint语句
/ipns/dahih-dolij-sozuk-vosah-luvar-fuluh
# 分解为相应的下面形式
/ipns/KhAwNprxYVxKqpDZ

缩短名称服务
会涌现出很多服务器提供缩短名称的服务，向用户提供他们的命名空间。就像我们现在看到的DNS和Web的URLs：

1
2
3
4

# 用户可以从下面获取一个link
/ipns/shorten.er/foobar
# 然后放到自己的命名空间
/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm

3.8使用IPFS

IPFS设计为可以使用多种不同的方法来使用的，下面就是一些我将会继续追求的使用方式：

• 1.作为一个挂载的全局文件系统，挂载在/ipfs和/ipns下
• 2.作为一个挂载的个人同步文件夹，自动的进行版本管理，发布，以及备份任何的写入
• 3.作为一个加密的文件或者数据共享系统
• 4.作为所有软件的版本包管理者
• 5.作为虚拟机器的根文件系统
• 6.作为VM的启动文件系统 (在管理程序下)
• 7.作为一个数据库：应用可以直接将数据写入Merkle DAG数据模型中，获取所有的版本，缓冲，以及IPFS提供的分配
• 8.作为一个linked（和加密的）通信平台
• 9.作为一个为大文件的完整性检查CDN（不使用SSL的情况下）
• 10.作为一个加密的CDN
• 11.在网页上，作为一个web CDN
• 12.作为一个links永远存在新的永恒的Web
  IPFS实现的目标：
• (a)一个IPFS库可以导出到你自己应用中使用
• (b)命令行工具可以直接操作对象
• (c)使用FUSE[?]或者内核的模型挂载文件系统

  4. 未来

  IPFS的思想是几十年成功的分布式系统的探索和开源的产物。IPFS综合了很多迄今为止很成功的系统中优秀的思想。除了BitSwap新协议之外，IPFS最大的特色就是系统的耦合以及设计的综合性。
  IPFS是去中心化网络基础设施的一个野心设想，很多不同类型的应用都可以建立在IPFS上。最低限度，它可以用来作为一个全局的，挂载性，版本控制文件系统和命名空间，或者作为下一代的文件共享系统。而最好的情况是，IPFS可以让Web升级一个层次，当发布一个有价值的信息时，任何感兴趣的人都可以进行发布而不会强迫性的必须只允许发布机构进行发布，用户可以信任信息的内容，信不信任信息的发送者都是无关紧要的，还有一个特点就是，一些重要但很老的文件也不会丢失。IPFS期待着带我们进入到一个永恒Wdb的世界。

  5. 感谢

  IPFS是一个很多很棒的主意以及系统的综合体。没有站在巨人的肩膀上，IPFS也不可能敢于有一个这么有野心的目标。个人感谢参与这些主意长期讨论的人：David Dalrymple, Joe Zimmerman, and Ali Yahya，特别是：揭开Merkle DAG的总体架构(David, Joe),滚动哈希阻塞(David), s/kademlia sybill 保护(David, Ali)，特别感谢David Mazieres,为他之前非常聪明的主意。

  6.引用备忘录

  7.引用

  [1].I. Baumgart and S. Mies. S/kademlia:一个安全的基于秘钥路由的可行方法。2007年国际会议，第2卷，1-8页，在《并发和分布式系统》中。IEEE，2007年。
  [2].I. BitTorrent.Bittorrent和Attorrent软件超过1亿5000万用户里程碑，Jan。2012
  [3].B. Cohen.激励机制在bittorrent中建立了健壮性。在《对等系统经济研讨会》中，第6卷，68-72页，2003年。
  [4].J. Dean and S. Ghemawat. Leveldb - 一个快速和轻量级键值存储数据库，谷歌提供，2011年。
  [5].M. J. Freedman, E. Freudenthal, and D. Mazieres. Coral民主内容发布。在NSDI中，第4卷，18-18页，2004年。
  [6].J. H. Howard, M. L. Kazar, S. G. Menees, D. A,Nichols, M. Satyanarayanan, R. N. Sidebotham, 以及M. J. West.分布式文件系统的规模和性能。“ACM 电脑系统上的交易 （TOCS）” 6(1):51-81, 1988年

Chain

简介

chain设计了一种多种资产可以互相交易发布的分布式账本协议。用该协议的多条链可以独立的存在， 并且可以跨链交易， 这样不同的运营商可以以相同的形式互相交易。坚持最小权限原则， 资产的管理和分布式账本同步控制相分离。
链协议允许任何网络参与者通过编写自定义“发布程序”来定义和发行资产。一旦发行，资产单元由“控制程序”控制。 控制程序是用图灵完备的编程语言实现， 该语言可用于编写复杂的智能合约。
每个网络由“块签名者“组成的联盟来保护安全性。 只要法定的块签名者遵循协议， 该系统就可以安全的抵抗分叉。为了提高效率，所有出块人可以达成协议， 委托单个节点出块，类似于raft协议。 网络的任何节点都可以验证块并广播交易。
Chain 主要是面向企业软件产品的联盟链。 Chain的代码是长久开源的， 并且搭建了一个测试链，供大家自由测试。

设计Chain 的动机

当今社会的货币， 证券以及衍生品是以电子支付的形式进行交易的。电子支付需要太多的第三方中介参与，需要太多的人力物力去对帐。比特币虽然去中介化了，但堆栈式脚本实现的功能太少， 只支持本币的简单交易合约。以太坊的evm 又太过于复杂， 有太多的安全不确定性。再者， 他们是公有链，所有数据在公众的眼皮底下。 这时， Chain 恰好能够解决这些痛点。 Chain 是联盟链，支持多种资产的发布和交易， 也支持多种组织的跨链交易。

Chain 大部分思想来自于比特币和以太坊。

• 1.在比特币的基础上增加了多种资产自由发布。而比特币只支持btc。
• 2.evm的功能介于比特币和以太坊之间。主要用于资产的发布与管理。
• 3.采用了比特币的utxo模式并且采用隔离见证的数据格式，交易状态和交易验证相隔离。
• 4.加入了以太坊的PAT树用于世界状态， 但该世界状态不是面向账户的， 而是面向utxo的。

基本数据结构

Chain 的目的是管理数字资产的发行、所有权、 交易。资产的发布、转让和交换是通过向网络发送交易来完成的。 这些交易会被排序并分批打包成块，然后组成一条不可更改的区块链。
资产
每条区块链都可以支持多种类型的资产。 每种资产被一个256位字节的全局资产ID 所定位唯一（在所有的区块链中该ID唯一）。每种资产ID有相对应的发布程序，它定义了该资产的发布规则。一旦资产发布，资产的支出由控制程序决定。
交易
交易使用比特币的UTXO模式。但在这些基础上做了改进， inputs 可以选择发布资产或者是未消耗的发费，outputs可以选择控制程序的输出或者资产的销毁，并且在inputs和outputs上加了个资产ID字段，支持多种资产的混合交易， 只要inputs和outpus的价值相等即可。如下图：

为了提高性能，交易实现了类似比特币的隔离见证功能， 如下图：

区块
为了防止双花，块引入了类似以太坊的世界状态，但世界状态是针对UTXO 存储的, 即每一笔交易的执行，都是在该世界状态中执行两步

• 1.删除原来的已经发费了的outputs。
• 2.增加产生的outputs。
  区块中存储每一笔排序的交易，并链接成一条不可更改的区块链。如下图
  
  所有的交易在每一个块中排序好，成为不可更改的历史事实。世界状态作为当前区块链的快照。 当然块与块之间少不了共识， 共识程序的执行流程类似于上上图交易验证的流程。（recover(signature + message) ?= pubkey）
  区块链的整体数据结构如下图：
  

程序设计

Chain 的协议使得编程非常灵活， 可根据不同的层次并行计算。

• 1.发行资产程序指定相应的规则发行新资产。
• 2.控制程序指定相应的规则在一种资产上作交易。
• 3.共识程序指定相应的规则产生新的区块。
  这些程序根据内存和时间的限制， 可以并行的运行。正因为如此，程序是足够灵活以允许实施广泛的金融工具（如期权、债券、互换），安全方案（存储资产），应用如提供，契据，拍卖。

  虚拟机(CVM)

  Chain 的虚拟机是一个栈式状态机： 任何指令都在该栈中执行。CVM 的指令集是图灵完备的，为了防止死循环， 采用了run limit 来限制陷入死循环， 协议允许网络去达成共识设置该run limit. 根据运行消耗来定价每一条指令的run limit。 这 非常类似于以太坊的gas机制， 和以太坊不同的是CVM 不会在每笔交易中给run limit 计费。CVM 指令集包含了push, pop等基本指令集， 同时还包括了SHA3, CHECKSIG, CHECKMULTISIG等复杂的数学加密运算。
  自省功能
• 交易自省： 可以在执行过程判断是否超过预定的时间，也可以增加自带控制程序，来对（价格，资产，运行过程， 索引）做一定自由控制。
• 区块自省： 自省指令集（BLOCKHASH, NEXTPROGRAM）,只能在共识程序中执行。
  因为丰富的指令集，可以组合使用完成不仅仅是交易签名和验签的功能。如：多重签名，多方签名，提前部署（我最喜欢的是：类似于微信红包功能， A给B发送交易，需要B确认才能上链）CHECKPREDICATE 提供了强大的其它跨链功能，包括实现类似于BTCRelay的功能。

  共识

  Chain 可以支持任意的共识程序， 目前实现的共识， 是不支持拜占庭容错的。 他是有N个节点对每个高度的块签名投票，当一个块收集到超过M个节点的签名时就出块。只要不超过2M-N-1的节点违反同时给同一高度的多个块签名投票， 就不会产生分叉。

  安全性

  Chain 支持M-N 多重签名控制程序， 支持M-1 签名的发布程序来保证资产的安全。
  隐私
• 1.链上登记，不需要第三方中介信任。
• 2.每一个控制程序都有一个唯一的公钥来防止同一个账户被别人发现。一个主密钥，该主密钥可以产生无数的公私钥对， 每次交易，不用主私钥，只需要衍生私钥， 这在一定程度上保证了安全性。
• 3.可以保证一些敏感数据的隐私， 如期限，价格和利率。 可以通过每个分支链的merkle 后的程序隐藏。 只有执行中的分支链需要执行期间被显示。这样的合约，可以在交易时多方签名认证，（私人合约链下解决， 在链上签名认证即可。）和合同在现实世界中的工作方式相似 - 虽然在法庭执行时通常要求将合同的条款公开，但大多数合同都是私下解决的，公共系统只能作为一个隐含的支持者。
• 4.共识安全性防范： 效率和安全不可兼得。
  监管
  Chain 允许本地的政策发布， 但监管方可以通过块生成器进行监管。如果块签名者在同一高度签署多个块，参与者可以使用不一致的签名来构建欺诈证据，以警告其他节点或为链下执行提供证据。

  伸缩性，扩展性， 互通性。

• 1.utxo 与以太坊账户模型不同， 可以并行验证交易， 只要用类似于nonce的机制保证每一个未花费outputs最多只能被一笔交易所引用。
• 2.Chain 天然的比以太坊瘦， 不需要完整的世界状态， 参与者只需要记住未花费的outpus就可了， 因为交易会自带其他相关信息（如资产ID, 量额， 控制程序）， 超级轻客户端。
• 3.compact 验证 ， 只允许客户端验证块中所相关的交易，而不需要验证所有的交易，只要信任签名者的数量即可。整个过程是用Merkle证明。客户端也可以将监视整个区块链的任务委托给自己信任的服务器。
  块可以通过软分叉的方式向前向后版本兼容。
  Chain 不仅支持在实现本协议的区块链间通信， 但需要保证全局唯一资产ID。每一条分链是从另外一条链的块高度叉出去的，根据这点能保证资产ID唯一。 并支持不同的协议的链互相交互， 因为CVM提供了足够多的指令。

星期四, 25. 五月 2017 10:06上午