【问题标题】:Endorsement Policy based on chaincode-method level基于链码方法级别的背书策略
【发布时间】:2018-08-18 19:31:53
【问题描述】:

我可以根据chaincode-method级别为chiancode设置背书策略吗?下面是场景::

我有两个函数,比如说 fun1() 和 fun2()。两个函数都在同一个链码中,比如说“test.go” 我有三个同伴,比如说 A、B 和 C

  • 对于 fun1(),我希望得到同行 A 和同行 B 的认可。
  • 对于 fun2(),我希望得到同行 B 和同行 C 的认可。

查询 ::

当所有函数/方法都在一个链码中时,我可以在 hyperledger-fabric 中指定不同的函数/方法级别的背书策略吗?

我在 hyperledger-fabric 文档中没有看到类似的内容来指定基于功能级别的背书策略。

“为链码指定背书策略”::

https://hyperledger-fabric.readthedocs.io/en/release-1.1/endorsement-policies.html#specifying-endorsement-policies-for-a-chaincode

我正在使用 Fabric v1.1,当相同的链码“.go”中存在不同的方法并且每种方法都需要获得不同对等方的认可时,有什么更好的方法来处理这种情况。 这是否意味着 :: “所有需要相同背书策略的业务逻辑都应该编码在相同的链码中?”。

听说,即将推出“基于状态的背书”这个新功能,不知道这个功能是否可以帮助我解决这个要求。

https://jira.hyperledger.org/browse/FAB-8812

提前感谢您的帮助。

【问题讨论】:

    标签: hyperledger-fabric hyperledger


    【解决方案1】:

    不,你不能。

    拥有这样的东西会削弱 Fabric 的安全性:

    假设我们有组织 A、B、C 和一个具有 2 个函数 fg 的链码,每个函数都有自己的背书策略:

    • 函数f的背书政策是AB
    • 函数g的背书政策是(A and C) or (B and C)。
    • f 控制资产转移,而 g 控制资产创建。

    由于您仅在一部分对等节点上执行交易,如果 AC 勾结,他们可以通过制作声称调用 的交易来不诚实地转移资产g,但是有一个人工读写集,实际上做了 g 不能做的事情(转移资产,只有 f 可以做的事情do) 并使用对应于组织 A 的身份的私钥和对应于组织 C 的身份的私钥对其进行签名。 当对等方验证此交易时,他们将使用 g 的背书策略,并且对系统的业务影响将是未经组织 B 同意移动资产,即使 f 的背书政策本应阻止这种情况发生。

    很明显,这是因为 Fabric 是一个执行订单验证区块链 - 交易在对等节点的子集上执行,并且如果交易的背书满足背书策略 - 你没有真正的方法知道交易是否诚实执行,因为对等方不知道如何根据读取集和链码提案创建交易写入集,因此无法区分恶意制作的交易和诚实的交易。

    听说,新功能“基于状态的背书”即将推出, 不确定此功能是否可以帮助我满足此类要求。

    不,它不会帮助你。基于状态的背书只是意味着可以为每个key显式指定背书策略,然后更新key或改变其背书策略需要满足背书策略,如果没有设置背书策略,则需要满足链码的背书策略。

    有关更多信息,您可以查看关于这个问题的讨论,包括提到基于状态的背书,FAB-11246

    【讨论】:

    • 我有非常相似的问题。基本上我有一个由三个组织组成的网络。两家银行和一家监管机构。资产分为三种。创建其中一项资产要求只有创建者银行可以创建该资产,其他银行不得以该资产属于其他银行的方式创建该资产。有一种资产需要银行和监管机构的背书才能创建。最后,当两家银行同意并需要两家银行的背书时,就会创建第三个资产,但交易的结果取决于其他类型资产的状态。
    【解决方案2】:

    感谢您的快速回复,对于延迟回复深表歉意。 如果我们尝试基于链码方法级别的背书策略,您的资产创建/转移示例清除了可能的信任问题。

    因此,我需要将我的链代码逻辑划分为单独的链代码文件并将其部署在两个单独的通道上,以便我可以为每个通道设置不同的背书策略。

    正如我从下面的 hyperledger-fabric 文档中了解到的那样,我正在尝试实现类似“动态添加背书策略”之类的东西,我认为这是不允许的。

    "3.1. 背书政策规范" ::

    https://hyperledger-fabric.readthedocs.io/en/release-1.1/arch-deep-dive.html#endorsement-policy-specification

    “因此,不允许动态添加背书策略, 但以后可以支持。”

    我很乐意听到 Hyperledger facric 社区在未来版本中探索更多关于这种“动态添加背书策略”的信息。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2021-01-07
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多