1）应⽤端⾸先构建交易的预案，预案的作⽤是调⽤通道中的链码来读取或者写⼊账本的数据。应⽤端使⽤ Fabric 的 SDK 打包交易预案，并使⽤⽤户的私钥对预案进⾏签名。
应⽤打包完交易预案后，接着把预案提交给通道中的背书节点。通道的背书策略定义了哪些节点背书后交易才能有效，应⽤端根据背书策略选择相应的背书节点，并向它们提交交易预案。 2. 背书节点处理
2）背书节点收到交易预案后，⾸先校验交易的签名是否合法，然后根据签名者的⾝份，确认其是否具有权限进⾏相关交易。此外，背书节点还需要检查交易预案的格式是否正确以及是否之前提交过（防⽌重放攻击）。 在所有合法性校验通过后，背书节点按照交易预案，调⽤链码。链码执⾏时，读取的数据（键值对）是节点中本地的状态数据库。需要指出的是，链码在背书节点中是模拟执⾏，即对数据库的写操作并不会对账本作改变，所有的写操作将归总到⼀个写⼊的集合（ Write Set ）中记录下来。
在链码执⾏完成之后，将返回链码读取过的数据集（ Read Set ）和链码写⼊的数据集（ Write Set ）。读集和写集将在确认节点中⽤于确定交易是否最终写⼊账本。
3. 返回响应结果
3）背书节点把链码模拟执⾏后得到的读写集（ Read-Write Set ）等信息签名后发回给预案提交⽅（应⽤端）。
gps信号转发器4.发送排序节点
4）应⽤端在收到背书响应之后，检查背书节点的签名和⽐较不同节点背书的结果是否⼀致。如果预案是查询账本的请求，则应⽤端⽆需提交交易给排序节点。如果是更新账本的请求，应⽤端在收集到满⾜背书策略的背书响应数量之后，把背书预案中得到的读写集、所有背书节点的签名和通道号发给排序节点。
5.排序节点处理
5）排序节点在收到各个节点发来的交易后，并不检查交易的全部内容，⽽是按照交易中的通道号对交易分类排序，然后把相同通道的交易
打包成数据块（ blob ）。链轮材料
6.发送交易区块
6）排序节点把打包好的数据块⼴播给通道中所有的成员。数据块的⼴播有两种触发条件，⼀种是当通道的交易数量达到某个预设的阈值，另⼀种是在交易数量没有超过阈值但距离上次⼴播的时间超过某个特定阈值，也可触发⼴播数据块。两种⽅式相结合，使得排序过的交易可以及时⼴播出去。
7.检验区块交易
u型管7）确认节点收到排序节点发来的交易数据块后，逐笔检查区块中的交易。先检查交易的合法性以及该交易是否曾经出现过。然后调⽤VSCC（ Validation System Chaincode ）的系统链码检验交易的背书签名是否合法，以及背书的数量是否满⾜背书策略的要求。接下来进⾏多版本并发控制 MVCC 的检查，即校验交易的读集（Read Set）是否和当前账本中的版本⼀致（即没有变化）。如果没有改变，说明交易写集（Write Set）中对数据的修改有效，把该交易标注为有效，交易的写集更新到状态数据库中。
超级电容器结构
如果当前账本的数据和读集版本不⼀致，则该交易被标注为⽆效，不更新状态数据库。数据块中的交易数据在标注成“有效”或“⽆效”后封装成区块（block）写⼊账本的区块链中。
套管挤压上述的交易流程中，采⽤了 MVCC 的乐观锁（ optimistic locking ）模型，提⾼了系统的并发能⼒。
需要注意的是，MVCC 也带来了⼀些局限性。例如，在同⼀个区块中若有两个交易先后对某个数据项做更新，顺序在后的交易将失败，因为它的读集版本和当前数据项版本已经不⼀致（因为之前的交易更新了数据）。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议