You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

生产环境中使用Hyperledger Composer的相关技术问题咨询

Hyperledger Composer API & Card Management for Non-Angular Frontends

我来帮你逐个梳理这些生产环境里的关键问题,都是实际落地时容易踩坑的点:

1. 卡片传递与前端网络连接问题

完全不需要把卡片直接传递给前端!卡片里包含私钥这类敏感信息,一旦传给前端,很容易被泄露或篡改,风险极高。

正确的做法是后端持有并管理卡片,前端只需要通过已认证的REST接口和后端交互:

  • 前端通过passport-jwt完成认证后,所有请求都会携带有效的JWT令牌,后端验证令牌的合法性后,使用自己持有的管理员卡片(或对应用户的专属卡片)去调用Hyperledger Composer的SDK操作区块链网络。
  • 比如前端需要创建新参与者时,只需向后端发送包含参与者信息的请求,后端验证身份后,调用Composer SDK的network.getParticipantRegistry()和add()方法完成创建,再把结果返回给前端。
  • 如果需要让前端代表特定用户执行操作,你应该在后端为该用户生成对应的专属卡片,加密存储在后端,前端通过JWT标识自己的身份,后端根据身份取出对应卡片执行操作,全程卡片不会离开后端环境。

2. 用户卡片的存储策略

绝对不要把用户卡片分发给终端用户!卡片是访问区块链网络的凭证,包含私钥等核心敏感信息,分发出去等于把网络访问权限交给了不可控的客户端,会带来极大的安全隐患。

正确的做法是:

  • 将用户卡片的JSON内容进行加密存储(比如用AES算法加密),密钥由后端安全保管(可以存在环境变量或专门的密钥管理服务中)。
  • 当需要使用某用户的卡片时,后端从数据库取出加密后的卡片内容,解密后加载到Composer SDK中使用,用完后及时清理内存中的敏感数据。
  • 所有卡片的创建、更新、销毁操作都在后端完成,前端完全接触不到卡片的具体内容。

3. 创建自定义API的几种方式

基于Hyperledger Composer构建自定义API,主要有三种常用方案,你可以根据业务复杂度选择:

方案一:扩展Composer REST Server

Composer REST Server基于LoopBack框架,你可以编写自定义的LoopBack控制器来扩展它:

  • 新建一个自定义控制器文件(比如custom-api.js),在里面定义自己的路由和处理逻辑,比如整合第三方服务、处理复杂的业务校验等。
  • 启动REST Server时,通过--custom参数指定这个控制器,比如:
    composer-rest-server -c admin@your-network -n never --custom custom-api.js
    
  • 这样你的自定义API就会和Composer自动生成的REST端点一起对外提供服务,适合快速扩展现有REST接口。

方案二:搭建独立的Node.js后端服务

如果需要完全控制API的设计和认证逻辑,推荐直接使用Composer Node SDK搭建自己的后端服务(比如用Express):

  • 在Node.js项目中安装composer-client和composer-common依赖。
  • 初始化Composer连接:加载管理员卡片(或用户卡片),获取区块链网络实例。
  • 编写自定义的Express路由,比如:
    app.post('/api/custom-participants', async (req, res) => {
      // 验证JWT令牌
      // 从请求体获取参与者信息
      const participant = factory.newResource('org.example', 'Participant', req.body.id);
      participant.name = req.body.name;
      // 获取参与者注册表并添加新参与者
      const participantRegistry = await network.getParticipantRegistry('org.example.Participant');
      await participantRegistry.add(participant);
      res.status(201).json(participant);
    });
    
  • 这种方式灵活性最高,适合复杂业务场景,能完全自定义API的请求响应格式、认证逻辑等。

方案三:结合链上事务处理器

把复杂的业务逻辑封装成Composer的事务处理器(Transaction Processor Functions),然后通过自定义API触发这些事务:

  • 在Composer业务网络定义中编写事务处理器,处理链上的业务逻辑(比如资产转移、权限校验等)。
  • 自定义API只需接收前端请求,调用Composer SDK触发对应的事务即可,这样把核心逻辑放在链上,保证数据的一致性和不可篡改。

内容的提问来源于stack exchange,提问作者Honey Shah

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.05.28 10:05:31