首页 文章

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

提问于
浏览
3

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

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

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

所有这些同行都加入了同一个 Channels channel1 . 我的要求是

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

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

1 回答

  • 4

    我认为由于您将应用程序逻辑与通常在链代码中实现的业务 Contract 逻辑混合在一起而导致混淆的原因 .

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

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

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

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

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

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

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

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

相关问题