在Hyperledger Fabric V1.0中,在同一个通道内的对等体之间实现通道间安全性

时间:2017-09-21 19:52:04

标签: blockchain hyperledger-fabric hyperledger

我已按照Building Your First Network步骤在本地成功创建了Hyperledger Fabric v1.0网络,并使用fabric-sdk-java从我的Java应用程序与此网络进行通信。
这里使用 cryptogen 工具创建证书,并且能够通过参与同一频道的每个对等方调用/查询链码。


我的实现如下:
我有四个组织Org1,Org2,Org3和Org4,每个组织都有一个同伴。 当Org1使用链码C1创建数量为100的资产A1时,它必须在对等方之间共享此资产,如

  

Org2.peer0 A1:数量为40
Org3.peer0 A1:数量   30
Org4.peer0 A1:数量为20   
剩下的只有10个   适用于Org1.peer0

所有这些同行加入了同一频道频道1 。 我的要求是

  

如果Org1尝试查询Org2的数据:错误
如果Org1尝试查询   它自己的数据:返回具有相应数量的资产。

目前,它允许查询通道中所有对等方的所有数据。为了保持一个组织的资产与其他组织的隐藏,最好的方法是什么?

1 个答案:

答案 0 :(得分:4)

由于您将应用程序逻辑与通常在链代码中实现的业务合同逻辑混合在一起,我认为这是您混淆的根源。

假设您希望在4个不同方之间建立Fabric网络,您需要定义一个规则,该规则定义您将如何在这些参与者之间拆分/分配资产。现在,让我们把对手放在一边。在您的链码中,您可以编码资产的概念,也可能是用户的概念,以避免混淆,让我们称之为人。所以你有4个人:爱丽丝,鲍勃,查理和约翰以及商业规则,这表明一旦爱丽丝提交资产,它必须分别按照40%,30%,20%和10%分配。

接下来,继续说Alice在Org1工作,Bob在Org2工作,Charlie在Org3工作,John从Org4工作。现在,您可以实现一个链代码,该代码将根据提交事务的人员应用业务规则。此外,您可以根据提交者身份实施ACL,从而防止Bob查询让我们说约翰的余额。

合法的问题是为什么我需要4个对等体来实现这样简单的逻辑。由于您只能部署一个带有链代码的对等体,因此为所有4个组织配置的通道以及您需要的只是发送事务提议以调用链代码。

这种方法的警告很明显,你需要决定哪个组织将托管并运行这个对等体和链码,因为所有4个组织都不相互信任,他们希望托管他们自己的同行和调用他们自己同行的链码。并且为了防止每个组织相互欺骗并减少对抗/非确定性行为的影响,他们将就认可政策达成一致,这些政策实际上将确保其他组织的同行在模拟过程中也会收到与您相同的结果。

现在回到你的问题,对等体用于模拟当前状态的交易并在结果上签名,将结果发送回客户端,根据策略聚合认可并将结果提交给订单服务,订购服务削减块并将其交付给对等体,它将验证块中事务的正确性,并最终将它们提交到分类帐更新状态。

因此,您的链代码应编码您将分配资产的客户/用户/人员的概念,这些用户可以映射回客户端应用程序(真实用户),这些用户可能会注册到不同的组织,因此具有不同的证书由适当的组织CA签署。最后,您将能够利用链代码的GetCreator API来了解哪个客户端调用了链代码,并根据您定义的业务逻辑应用业务逻辑和访问控制。

很抱歉我的答案太长了,但总结一下。您的应用程序/服务将基于两层:第一层是应用程序层 - 映射到组织用户,第二层是持有分类帐和部署链代码的对等层 - 用于模拟和执行事务。因此,您将拥有4个对等体和4个客户端,它们将向对等体提交事务,您的逻辑将基于客户端身份而非对等体。

希望我的解释对你有意义;)