hyperledger fabric

token：

token是一种身份验证方式。

传统身份验证：

传统方式是使用session，即在用户登录时记录用户信息并生成一个ID，客户端在下一次访问时会带着这个ID，因此直接验证ID即可。而这份记录就是session，存在服务端中，可能需要定期清理。

换成token：

实际上和传统的方式没有多大区别，只是把ID换成token的信息：head，payload，signature。只是token更安全。

fabric通道：

通道是指两个或多个特定网络成员之间的通信的私有“子网”，用于进行需要数据保密的交易。channel由成员（组织）、每个成员的锚点（peer）、共享账本，链码应用程序（chaincode）和order服务节点定义。网络上的每个transaction都在一个channel上执行，每个通信方必须经过身份验证并授权在该channel上进行交易。加入channel的每个peer都具有由成员服务提供商（MSP）给出的自己的身份。

channelEventHub：

由于fabric对于事件的处理是跨越了多个组件（应用，背书节点，排序服务以及提交节点），这会花费较长的时间，因此需要采取异步操作。在事件被背书后但是在事件被发布到排序节点之前。应用需要注册一个监听器，以便在事务达到最终时通知事件，即时间将要提交到区块链上时。

交易（transaction）：

链码执行的操作，可以分为部署交易和调用交易。
部署交易：创建新的链码并设置一个程序作为参数。当一个部署交易执行成功，表明链码已被安装到区块链上。
调用交易：调用交易引用链码提供的一个函数。当成功时，链码执行特定的函数-它可能涉及修改相应的状态，并返回一个输出。

状态（state）：

区块链的状态被建模为一个版本键/值存储（KVS key/value store），键的名称和值可以是任意的。整体上由运行在区块链上的链码进行操作，通过存和取KVS操作实现。这个KVS一般以JSON的形式存储在数据库中，fabric支持couchdb的数据库存储。

账本（Ledger）：

账本提供了在系统运行过程中发生的可验证历史，它包含所有成功的状态更改（有效交易）和不成功的状态更改尝试（无效交易）。
账本是由排序服务(ordering service)构建的一个全部有序的交易哈希链块（有效的或无效的）。哈希链强制将全部排序块置入账本，每个块包含一批全部排序交易。这个强制全部排序覆盖所有交易。
每个peer节点都保存有账本，而orderer节点负责实现容错。

节点：

• 客户端节点：客户端代表最终用户实体，必须连接到一个peer节点以便与区块链交互。客户端可以选择连接任何peer节点，并进行交易。
• peer节点：可以提交交易、维持状态和账本的拷贝。此外，peer节点可以有一个特殊的背书角色。
• orderer节点：实现共识广播，排序服务（ordering service）为客户端和peer节点提供共享的channel，为包含交易的消息提供广播服务。客户端连接到channel，可以在channel上广播消息，随后channel将消息传递给所有peer节点。

链代码（chaincode）：

布置在节点上运行的程序。

背书策略：

对一份交易进行签名表示对该交易支持和信任，提高可信任度。通过制定背书策略使交易的可信任度达到某种程度才能运行该交易。

通道（channel）：

用于保证节点间执行某种交易。由于fabric是联盟链，因此只有加入通道的成员才能执行交易并保证交易的公平性。

成员服务提供者（MSP）：

作用是管理fabric中的众多成员，提供包括身份信息，身份认证在内的功能。MSP将颁发与校验证书，以及用户认证背后的所有密码学机制与协议都抽象了出来。一个MSP可以自己定义身份，以及身份的管理（身份验证）与认证（生成与验证签名）规则。

hyperledger fabric交易流程：

• 首先客户端需要通过SDK进行注册和登录，获得身份的认证和证书（CA）。
• 客户端可以发起一个交易提案（proposal），交易提案把带有本次交易要调用的合约标识、合约方法和参数信息以及客户端签名等信息发送给背书（Endorser）节点。
• 背书（Endorser）节点收到交易提案（Proposal）后，验证签名并确定提交者是否有权执行操作，同时根据背书策略模拟执行智能合约，并将结果及其各自的CA证书签名发还给应用程序客户端。
• 应用程序客户端收到背书（Endorser）节点返回的信息后，判断提案结果是否一致，以及是否参照指定的背书策略执行，如果没有足够的背书，则中止处理；否则，应用程序客户端把数据打包到一起组成一个交易并签名，发送给Orderers。
• Orderers对接收到的交易进行共识排序（排序的原因是为了保证交易的执行顺序，因为可能同一时间有很多交易被接受，因此需要执行共识算法对交易排序），然后按照区块生成策略，将一批交易打包到一起，生成新的区块，发送给提交（Committer）节点；
• 提交（Committer）节点收到区块后，会对区块中的每笔交易进行校验，检查交易依赖的输入输出是否符合当前区块链的状态，完成后将区块追加到本地的区块链，并修改世界状态。

couchdb嵌入：

使用couchdb作为状态数据库，当把资产建模为JSON并使用couchdb时，那么就可以使用chaincode中的CouchDB JSON查询语言对chaincode数据值执行复杂的富查询，这些类型的查询对于理解账本上的内容很有帮助。

例子：

官方marbles案例使用了fabric-SDK-node实现的交易。在fabric-sample中有balance-transfer。更有大神的解析