关于Hyperledger Fabric与Composer的三项技术问题咨询

嘿，我来帮你拆解这几个Hyperledger相关的核心问题，都是企业级区块链里的关键知识点：

问题1：Hyperledger Composer与Hyperledger Fabric的区块链运作机制 #

首先得明确，Hyperledger Composer是Hyperledger Fabric的上层开发框架，它的作用是把Fabric底层复杂的细节封装起来，让开发者能更高效地构建区块链应用，而底层的核心运作还是依赖Fabric的区块链网络。

先说说Fabric的基础运作流程：

• Fabric是许可制区块链，网络里的节点（Peer、Orderer、CA）都是经过授权的。客户端要先通过CA（证书机构）获取身份证书，才能参与网络。
• 当客户端发起交易时，首先会把交易提案发给指定的背书节点（Peer），这些节点会调用链码（智能合约）模拟执行交易，生成交易结果和背书签名，返回给客户端。
• 客户端收集到足够的背书后，把交易提交给Orderer节点（排序节点），Orderer负责把所有交易排序、打包成区块，分发给所有Peer节点。
• Peer节点收到区块后，会验证交易的背书是否符合预设的策略、交易是否合法，验证通过后就会把区块写入本地账本（包括不可篡改的区块链账本和用来快速查询的世界状态数据库）。

而Hyperledger Composer在这个流程里的角色是：

• 提供了一套简化的建模工具（比如CTO建模语言），让你可以快速定义资产、参与者、交易类型，不用直接去写Fabric的链码结构。
• 允许你用JavaScript编写交易逻辑（也就是所谓的智能合约脚本），Composer会自动把这些脚本转换成Fabric能识别的链码（支持Go或Node.js链码），部署到Fabric网络上。
• 还提供了REST服务器、SDK等工具，让客户端应用可以更轻松地和区块链网络交互，不用手动处理Fabric底层的提案、背书、排序等复杂步骤。

问题2：Hyperledger Fabric无挖矿的运作方式 #

挖矿是公链（比如比特币）用来解决“去中心化记账权竞争”和“拜占庭容错”的手段，但Fabric作为许可制的企业级区块链，根本不需要挖矿——因为所有节点都是经过授权的，不存在匿名节点恶意捣乱的问题，所以它用了一套更高效的共识机制来运作：

核心流程分为三步：

1. 交易背书：客户端发起交易提案后，只有符合预设背书策略的节点（比如某个组织的2/3 Peer节点）会执行交易模拟，生成背书签名。这一步确保交易是经过授权的节点认可的。
2. 交易排序：客户端把背书后的交易发给Orderer节点，Orderer用Raft或Kafka这类共识算法来给交易排序、打包成区块。比如Raft是拜占庭容错的共识算法，节点会选举出一个Leader来负责排序，其他节点同步数据，整个过程不需要算力竞争，效率极高。
3. 区块验证与提交：Peer节点收到区块后，会做几件事：验证交易的背书是否符合策略、交易是否被篡改过、模拟执行的结果是否和背书里的一致，没问题就把区块写入账本，更新世界状态。

简单来说，Fabric靠授权节点的背书+有序共识排序替代了挖矿，既保证了交易的合法性，又大幅提升了交易处理速度，完全适配企业场景的需求。

问题3：Hyperledger Composer中JavaScript交易与区块链的交互运作方式 #

在Composer里用JS写交易逻辑，本质是通过Composer的封装层和Fabric底层区块链交互，整个流程非常清晰：

1. 定义交易模型：首先你需要用CTO文件定义交易的结构，比如一个资产转移交易：

   namespace org.example.basic
   transaction TransferAsset {
       --> Asset asset
       --> Participant newOwner
   }
   

2. 编写JS交易逻辑：接着用JS实现这个交易的具体逻辑，Composer提供了一系列内置API让你操作账本数据，比如：

   /**
    * 处理资产转移交易
    * @param {org.example.basic.TransferAsset} tx 交易对象
    * @transaction
    */
   async function transferAsset(tx) {
       // 修改资产的所有者
       tx.asset.owner = tx.newOwner;
       // 获取资产注册表
       const assetRegistry = await getAssetRegistry('org.example.basic.Asset');
       // 更新资产到账本
       await assetRegistry.update(tx.asset);
   }
   

3. 部署与链码转换：当你把Composer项目部署到Fabric网络时，Composer会自动把你的JS脚本转换成Fabric的链码（比如Node.js链码），部署到指定的Peer节点上。
4. 交易执行流程：
   • 客户端通过Composer SDK或REST API提交交易请求，Composer会把请求转换成Fabric的交易提案，发给背书节点。
   • 背书节点执行对应的链码（也就是你写的JS逻辑），模拟修改世界状态，生成背书签名后返回给Composer客户端。
   • Composer收集到足够的背书后，把交易提交给Orderer节点排序、打包成区块。
   • Peer节点验证区块合法后，写入账本，同时Composer会把交易成功的结果返回给客户端。

这里要注意，你写的JS脚本里的API（比如getAssetRegistry）都是Composer封装好的，底层会调用Fabric链码的API来访问账本，你不用关心Fabric底层的细节，只需要专注于业务逻辑即可。

内容的提问来源于stack exchange，提问作者Jony