You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Frequently asked questions (FAQ) or Questions and Answers (Q&A), are listed questions and answers, all supposed to be commonly asked in some context, and pertaining to a particular topic. The format is commonly used on email mailing lists and other online forums, where certain common questions tend to recur.

General 


  • Q: `Hyperledger`和`Ethereum`的区别是什么?为什么这么多企业用`Hyperledger`而不是`Ethereum`?
    A: 超级账本面向企业应用场景,侧重联盟链。2018年10月,超级账本和以太坊企业联盟发布合作。2019八月,Consensys 创业公司PegaSys贡献了以太坊客户端Pantheon项目,并命名为超级账本Besu,

Hyperledger Fabric 


  • Q: `Fabric`接下来的发展方向有哪些?
    A: 更强的隐私保护(零知识证明)、更多的共识机制(Raft、BFT)、更好的管理和使用(配合 Cello 项目)等。
  • Q:`Ethereum`面临很多安全方面的问题,请问`Fabric`现在是否也面临一些安全性相关的问题呢?
    A: 无论对于以太坊还是fabric或者其他的区块链框架,只要智能合约的可拓展性达到图灵完备的级别,则必然会像其他所有的软件项目一样遇到安全攻防问题。没有银弹,传统的安全审计,黑白盒穿透测试仍然可以有助于预防和解决具体项目中的问题。
  • Q: Endorser根据什么信息判断是否给某个具体的transaction endorse
    A: 目前主要检查权限策略,用户也可以自定义 ESCC。1.3版本引入的新的背书策略,使得颗粒可细化到数据库键值级别,详情可搜索key level endorsement policies
  • Q: 交易如何保证无关人员不能查看,从而保证隐私呢?通过交易证书吗? 登记证书应该是保证用户和节点的身份信息。
    A: 目前,主要通过通道、sideDB 等特性保护隐私。也可以在智能合约里通过交易发起人的证书通过合约代码逻辑做认证。此外,1.2版本引入了更细化的通道接入权限控制,详情搜索Access Control Lists (ACL)
  • Q: `Fabric`性能怎么样,有没有可靠的测试报告
    A: Hyperledger Caliper可以用于做fabric的基准测试
  • Q: 目前 Fabric 的orderer相当于一个中心化的节点,感觉这与分布式和区块链有点违背?
    A: 支持多个 Orderer,分布式合作实现排序服务。
  • Q: SBFT目前是否有任何时间表?
    A: 暂时没有。
  • Q: `Fabric`应用于物联网系统有没有推荐的方法?现阶段嵌入式设备可以部署成`Fabric`节点吗?
    A: 建议把设备端作为Fabric的Client。 出于运算和存储能力的考虑,不建议直接部署 Fabric节点
  • Q: 目前对于`Fabric`的可回溯性,除了一笔一笔交易去遍历,还有什么比较好的方法吗?
    A: 对于某个特定的key, 可以通过合约内的ChaincodeStub.GetHistoryForKey API去查询它的值历史
  • Q: 相较`Hyperchain`等联盟链的“万级”TPS,导致`Fabric`性能不高的原因有哪些?
    A: Fabric 目前单通道暂时只能达到 1~20 K 的TPS,限制其性能的因素包括本地硬盘读写速度、CPU 核数和网络吞吐,本质上是由于其间多次的非对称加解密操作。
  • Q: Fabric 的链码对于调用者是完全可见的吗?就是说每个链码的调用者都能看到链码的逻辑吗?
    A: 调用者属于客户端,一般情况看不到服务端的链码逻辑。如果客户端权限足够且peer开启了生命周期链码,可以通过lscc的api获取链码数据
  • Q: fabric网络完全启动后,不停止网络的情况下,能够完成排序服务的切换吗?比如卡夫卡切换为solo
    A: kafka切换为solo暂时不支持,但是从1.4.2开始,官方文档提供了将kafka切换成RAFT的方法
  • Q: 我们每次初始化或者升级chaincode的时候,都会新建一个新的链码 docker 镜像和容器,如果我们想定制化默认的链码镜像,比如预先安装一些其他应用,使得初始化的时候有一个预期的环境, 我们应该如何做?镜像的Dockerfile在哪里呢?

    A: 每个类别的链码(Go, Java, Nodejs)有着对应的Dockerfile不过Dockerfile的内容实际上是内嵌在节点二进制程序文件里面的,因此除非修改节点程序本身,否则你无法修改Dockerfile的内容。在接下来2.0的版本里,你将会可以构建你自己的链码启动器,因此,将可以如你所愿的任何方式来构建/部署链码。 实际上与此同时,你既可以修改用于构建链码的镜像,也可以修改用于运行链码的镜像

    关于构造:
    在1.4.x的版本中,Go和Nodejs的链码是用fabric-ccenv的镜像来构建的(你可以在Fabric源码中images/ccenv目录下找到Dockerfile)。如果你构建时需要任何额外的库,你可以基于fabric-ccenv来构建自己的镜像。要特别注意的是,对Go链码来说我们只会采用编译后的二进制链码文件,该文件是在实际的链码容器里构建和使用的。类似地,Nodejs链码中我们采用的是已安装的node 应用(包含
    node_modules).通过设置peer 配置文件里chaincode.builder属性,你可以指定你自己的链码构造器为你定制的镜像。特别要注意的是java实际上是用"chaincode.java.runtime"镜像来构造的(你可以在fabric-chaincode-java代码仓库里找到fabric-javaenv)。
    在2.0中,Nodejs链码使用fabric-nodeenv镜像(在fabric-chaincode-node代码仓库里)而不是fabric-ccenv镜像


    关于运行:
    在1.4.x,fabric-ccenv镜像会构建链码二进制文件/Nodejs应用,以用于构建世纪的链码镜像。本质上,它只是复制了这些内容到运行时镜像里(通过配置文件里的"chaincode.golang.runtime", "chaincode.java.runtime", "chaincode.node.runtime"属性来指定)。因此,假如你的Go链码需要调用了外部共用库,你可以将他们添加到适当的基础运行时镜像里。对于Go链码来说是fabric-baseos镜像,对于Nodejs链码来说是fabric-baseimage
    在2.0中,Nodejs链码也是使用的fabric-nodeenv作为运行时镜像


  • Q: Fabric相关的代码仓库迁移到github这个过程的现状
    A:  状态追踪英文文档
    -  已迁移的仓库:fabric-gateway-java, fabric-chaincode-node, fabric-samples, fabric-amcl, fabric-ca, fabric-chaincode-evm, fabric-chaintool, fabric-docs, fabric-sdk-go, fabric-sdk-java, fabric-chaincode-java
    -  待迁移的仓库:fabric-test, fabric, fabric-baseimage(此仓库即将deprecate), fabric-sdk-node, fabric-cli, fab-lib-go, fabric-sdk-py

文档与国际化 

  • Q:Hyperledger中文文档在哪里?
    A: 目前有两处,一是原来使用的文档管理方式,见这里,以后不再更新;二是最近采用的新的翻译工具Zanata管理方式,见这里。后一种方式的工作正在进行中,欢迎贡献。
  • Q: Hyperledger文档国际化如何贡献?
    A: 参照这里
  • Q: 对于Hyperledger国际化,我能贡献哪些内容?
    A: 包括但不限于Hyperledger下各子项目(如fabric、cello等)的官方文档译文、官方设计文档译文、个人整理总结以及区块链相关知识的分享。请注意,目前使用的新的Zanata翻译方式只支持译预先上传的fabric官方原文,其他资源可直接贡献至GitHub,具体问题可联系yls@chainnova.com
  • No labels