这里似乎有很多问题。让我一步一步地解释一下。如果有不清楚或错误的地方,请您提出意见。
Fabric被设计为一种联盟区块链系统,广泛应用于企业业务场景中。在Fabric业务网络中,每个组织通常至少包含一个对等节点(peer),以及可选一个CA。
可以将一个业务场景想象为这样:几家公司想要共同开展业务。然而,它们之间的信任度不够高。因此,它们决定使用Fabric来解决这个问题。假设该网络包含3家公司(orgs),每家公司(org)都有一个peer和一个ca。
现在业务网络已经建立好了。
首先,让我解释一下enroll这个概念。
- 每个组织的ca都有一个引导用户,这个用户通过用户名和密码来访问,通常示例会使用admin/adminpw。在ca服务器设置期间,这个引导用户会被写入CA的db中。设置完成后,引导用户会被注册,但是没有被enroll。
- 接下来是
注册引导用户(enroll the bootstrap user)
。在这一步中,fabric-sdk(稍后我将使用sdk)首先生成私钥/公钥对,然后生成CSR(证书签名请求),最后使用私钥对CSR进行签名,并将已签名的CSR发送给fabric-ca服务器。 - Fabric-ca服务器收到已签名的csr时,将为该用户生成证书。该证书包含用户的公钥。Fabric-ca将使用自己的私钥对此请求进行签名,并将其签名附加到证书上。
- sdk从fabric-ca服务器获取响应(即步骤3中的证书)。fabric-sdk将证书和用户的私钥一起放在一起(我们称之为注册),作为
enroll()
方法的响应返回。
- 现在引导用户具有其注册信息,并可以使用此注册信息访问fabric网络。
我们可以使用引导用户在此org中注册和注册新用户。这就是为什么我们将财团区块链系统称为权限区块链系统的原因。
第二,让我解释sdk KVS(键值存储)的概念。
我们已经从上述步骤中获取了用户的私钥和证书。那么我们如何持久化这些数据呢?有几种选择,可以将其存储在应用程序层数据库中、一些硬件加密钱包中、一些基于云的HSM中等。
Fabric-sdk提供了一个KVS来完成此操作。这是一个可选项,您可以选择使用它或不使用它。坦率地说,我不建议在生产系统中使用它。如果您只是想尝试或测试某些内容,那么这很好,因为它非常简单。
默认情况下,fabirc-sdk-node将使用文件系统KVS。它将凭据存储在磁盘中,这就是您提到的hfc-key-store文件夹。
KVS被盗会发生什么?
所有注册信息都被盗了。所有证书和私钥都被盗了。攻击者可以使用这些证书和私钥以这些证书中的身份访问区块链系统。这是一场灾难。
createUser()用于什么?
不要把注册信息存储在文件系统中,而是更好地将其存储在应用程序层的数据库中。每次我们想要访问区块链系统时,我们可以先从数据库中查询并获取证书和私钥。然后使用createUser()
接口创建新的用户实例。该用户实例用作身份来访问区块链系统。
最后,让我解释一下Hyperledger Fabric中的交易流程
如果我们没有有效的用户证书和私钥,我们如何向Fabric网络发送交易?Fabric节点如何验证交易并知道我的身份?
- 每个交易都包含用户的身份信息。如果您要使用
userA
提交交易,则在进一步背书调用之前,应调用setUserContext(userA)
。
- 交易提案包含消息头中用户的证书。在将交易发送到Fabric节点之前,SDK将使用当前用户的私钥对此交易提案进行签名。
- 在对等方的一侧。当对等方收到认可请求时,对等方将使用fabric-ca的根证书来验证此请求中的证书,以便对等方知道此请求来自由已知CA颁发的身份,现在证书是可信的。然后对等方将解析证书并获取身份的公钥,然后使用此公钥验证交易的签名(我上面描述了tx是由私钥签名的,现在由公钥验证),现在交易是可信的。
从交易流程中,我们了解到交易必须使用用户的证书发送,并由用户的私钥签名。这就是为什么我们在fabric-sdk中设计了setUserContext()
接口。
cryptogen工具
该工具用于在系统设置期间生成私钥/公钥对和相应的证书。之后,我们需要一种动态添加/删除身份的机制。解决方案是Fabric-ca。
请注意,fabric-ca是可选的,您可以使用任何其他CA。