我有两个函数，比如fun1（）和fun2（）。这两个函数使用相同的链码，例如“ test.go” 我有三个同龄人，比如说A，B和C
查询::
在hyperledger-fabric文档中，我看不到类似功能可以基于功能级别指定认可策略。
“指定链码的背书策略” ::
我正在使用Fabric v1.1，当相同的链码“ .go”中存在不同的方法，并且每种方法都需要获得不同同行的认可时，有什么更好的方法来处理这种情况。 这是否意味着::“需要相同批注策略的所有业务逻辑都应使用相同的链码进行编码？”。
我听说，这项新功能即将推出“基于州的认可”，不确定该功能是否可以帮助我满足此类要求。
https://jira.hyperledger.org/browse/FAB-8812
预先感谢您的帮助。
答案 0 :(得分：3)
不，您不能。
有这种事情会破坏Fabric的安全性：
假设我们拥有组织 A，B，C 和具有两个功能的链代码，每个功能都有自己的认可政策， f 和 g ：
由于您仅在部分对等方上执行事务，因此如果 A 和 C 相互勾结，它们可以通过制定声称调用的事务来不诚实地转移资产。 g ，但具有人工读写集的设备实际上执行了 g 做不到的事情（转移资产，只有 f 可以做的事情并使用与组织 A 的身份相对应的私钥和与组织 C 的身份相对应的私钥对其进行签名。 当对等方验证此交易时，他们将使用 g 的背书策略，对系统的业务影响将是未经组织 B 同意就转移资产。 ，即使 f 的背书政策应该可以阻止这种情况的发生。
很明显，发生这种情况是因为因为Fabric是一个执行订单验证的区块链-交易是在对等方的子集上执行的，并且如果背书策略满足了交易的背书-您就没有真正的方法因为对等方不了解如何根据读取集和链码提议创建交易写集，所以知道交易是否是诚实执行的，因此无法区分恶意制作的交易集和诚实的交易集。
我听说，这项新功能即将推出“基于国家的认可”， 不确定此功能是否可以满足我的要求。
不，它不会帮助您。基于状态的认可只是意味着可以为每个密钥明确指定认可策略，然后更新密钥或更改其认可策略，您需要满足认可策略，并且如果未设置认可策略，则需要满足chaincode的认可政策。
有关更多信息，您可以在-FAB-11246
中查看有关此问题的讨论，包括基于州的认可。答案 1 :(得分：0)
感谢您的快速回复，并感谢您延迟回复。 如果我们尝试尝试基于链码方法级别的认可策略，则您的资产创建/转移示例可以消除可能的信任问题。
因此，我需要将链码逻辑划分为单独的链码文件，并将其部署在两个单独的渠道上，以便为每个渠道设置不同的认可策略。
据我从超级账本结构文档下面了解，我正在尝试实现一些“动态添加认可政策”，但我认为这是不允许的。
“ 3.1。认可政策规范” ::
“因此，不允许动态添加背书政策， 但将来可以支持。”
我希望听到Hyperledger的社区在以后的发行版中更多地探索这种“动态添加认可政策”。