https://cdn.jsdelivr.net/gh/wefantasy/FileCloud/img/fantasy-r.png

Hyperledger Fabric 使用 CouchDB 和复杂智能合约开发

在上个实验中,我们已经实现了简单智能合约实现及客户端开发,但该实验中智能合约只有基础的增删改查功能,且其中的数据管理功能与传统 MySQL 比相差甚远。本文将在前面实验的基础上,将 Hyperledger Fabric 的默认数据库支持 LevelDB 改为 CouchDB 模式,以实现更复杂的数据检索功能。此外,对上个实验的简单智能合约进一步进行功能上和设计上的扩展,最终实现了智能合约的分包、分页查询、多字段富查询、查询交易历史记录等功能。

label studio 结合 MMDetection 实现数据集自动标记、模型迭代训练的闭环

一个 AI 方向的朋友因为标数据集发了篇 SCI 论文,看着他标了两个多月的数据集这么辛苦,就想着人工智能都能站在围棋巅峰了,难道不能动动小手为自己标数据吗?查了一下还真有一些能够满足此需求的框架,比如 cvatdoccanolabel studio 等,经过简单的对比后发现还是 label studio 最好用。本文首先介绍了 label studio 的安装过程;然后使用 MMDetection 作为后端人脸检测标记框架,并通过 label studio ml 将 MMDetection 模型封装成 label studio 后端服务,实现数据集的自动标记[^1];最后参考 label studio ml 示例,为自己的 MMDetection 人脸标记模型设计了一种迭代训练方法,使之能够不断随着标记数据的增加而跟进训练,最终实现了模型自动标记数据集、数据集更新迭代训练模型的闭环。

Hyperledger Fabric 智能合约开发及 fabric-sdk-go/fabric-gateway 使用示例

在上个实验 Hyperledger Fabric 多组织多排序节点部署在多个主机上 中,我们已经实现了多组织多排序节点部署在多个主机上,但到目前为止,我们所有的实验都只是研究了联盟链的网络配置方法(尽管这确实是重难点),而没有考虑具体的应用开发。本文将在前面实验的基础上,首先尝试使用 Go 语言开发了一个工作室联盟链的项目信息智能合约,并成功将其部署至联盟链上;然后依据官方示例,使用 fabric-gateway 模块实现了一个能够管理项目信息智能合约的客户端;之后对比了 fabric-gateway 模块和 fabric-sdk-* 模块各自的优缺点,分析官方示例源码实现了通过 fabric-sdk-* 模块管理整个联盟链网络。一般语境下,本文默认智能合约等于链码。

Handle 标识解析系统从入门到能用

本文首先介绍了 Handle 的安装方式,并以默认方式启动了 Handle 服务,实现了本地标识解析的增删改查;然后针对默认 Handle 服务使用小众数据库 Berkeley DB 不利于调试和数据管理等问题,参考官方技术手册实现了将其迁移到更流行的 MySQL 数据库上,并对相关数据表进行分析介绍;最后针对未购买权威前缀无法本地授权调试的问题,通过分别配置本地客户端和服务端的运行方式,实现绕过 Handle 官方根节点进行本地授权登录,最终搭建起自己的全局根节点服务。

MMDetection 使用示例:从入门到出门

最近对目标识别感兴趣,想做一些有趣目标识别项目自己玩耍,本来选择的是 YOLOV5 的,但无奈自己使用 YOLOV5 环境训练模型时,不管训练多少次 mAP 指标总是为 0,而其它 pytorch 项目却能正常运行,尝试解决无果后发现另一个更好用的目标识别库——MMDetection ,最终实现了自己的需求。本文首先介绍了 MMDetection 库在 Windows 11 下的安装方式,及可能遇到的问题和解决方法;然后说明了其自带的单图片检测、视频检测、摄像头检测工具的使用方法,并在此之上扩展了一个同时包含上述功能并且能够批量检测图片的 Python 代码;最后以数据集 CelebA 数据集为例,详细记录了使用 MMDetection 训练私有数据集的方法。

Hyperledger Fabric无排序组织以Raft协议启动多个Orderer服务、TLS组织运行维护Orderer服务

在实验 Hyperledger Fabric无排序组织以Raft协议启动多个Orderer服务、多组织共同运行维护Orderer服务 中,我们已经完成了让普通组织运行维护 Orderer 服务,但是最后发现由于运行排序服务的组织需要较为开放的访问策略,可能会降低组织的安全性,所以本实验将尝试使用提供 TLS-CA 服务的 council 组织运行维护 Raft 协议的三个 orderer 节点。本文将在之前的实验基础上,启动一个没有 orderer 组织的 Fabric ,其中由 council 组织提供排序服务,其余三个组织维护着各自的 peer 节点,最后成功在其上部署运行链码。

Hyperledger Fabric无排序组织以Raft协议启动多个Orderer服务、多组织共同运行维护Orderer服务

在Hyperledger Fabric无系统通道启动及通道的创建和删除中,我们已经完成了以无系统通道的方式启动 Hyperledger Fabric 网络,并将链码安装到指定通道。但目前为止,实验中的 orderer 服务都是通过单独的排序组织来维护且只有一个,那能不能不要排序组织而使用普通组织来运行维护多个 orderer 服务呢?当然是可以的,本文将在之前的实验基础上,启动一个没有 orderer 组织的 Fabric 网络,网络中包含三个组织且每个组织运行维护着一个 orderer 节点,最后成功在其上部署运行链码。

Hyperledger Fabric无系统通道启动及通道的创建和删除

在 Hyperledger Fabric组织的动态添加和删除 中,我们已经完成了在运行着的网络中动态添加和删除组织,但目前为止,我们启动 orderer 节点的方式都是通过系统通道的方式,这样自带系统通道的网络很不简洁优雅。好在 Fabric 2.3 以上就开始支持无系统通道创建应用通道的功能,本文将对此功能进行详细解释和介绍,然后通过无系统通道的方式启动联盟链网络并在此基础上完成通道的添加和删除。