编辑：凹凸-任何人都知道答案吗？
基本问题：-在单个HLF应用程序中，不同的交易可以具有不同的密钥吗？
上下文：开发一个1.4.2 HLF应用程序，该应用程序可镜像织物样本商业用纸示例，但具有不同的交易密钥。例如，在商业用纸中，PaperNet商业用纸的key是通过将Issuer和paper属性（例如， MagnetoCorp0001。 Issuer和paper可能会发生变化，paper始终与Issuer结婚。这在整个商业票据示例中都是一致的。
但是，在我们的示例中，根据状态，不同的事务将具有不同的密钥。例如，PartyA与BigBiz签订了一项合同，能够付费许可小部件。我们认为这是contracting transaction，完成后的状态是underContract，key的状态是licensor + licensee + contractNumber的串联，或者在此示例中：BigBizPartyA123。
在整个生命周期中，需要签订合同，BigBiz才能提供可用于许可的小部件。 available的{{1}}状态密钥为available widget transaction + licensor，在这种情况下为widgetID。
在我们的BigBiz0001中，用于licensing transaction状态的密钥是licensed + licensor + widgetID或licensee。
问题-这现实并且可行吗？
与始终存在BigBiz0001PartyA的商业票据不同，除非paperNum达到contracting transaction状态，否则生命周期POV中的我们的应用程序将没有widgetID。因此，没有可以键入的widgetID。同样，我们还有其他交易（例如付款交易）也与小部件无关，因此我们要输入underContract + licensor。
在复杂的HLF应用程序中这是正常现象吗？谢谢。
答案 0 :(得分：0)
您的问题似乎与1）管理唯一密钥以及状态/状态列表有关，以及2）什么是资产，交易的AND参数（以适当地应用于资产生命周期或参与者生命周期）。是的，如您所描述的，拥有不同的键是正常的。
首先，请参考Fabric文档-> https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/architecture.html#logical-representation
中“流程和数据设计”部分的“多状态”注释中的逻辑和物理表示形式。如果您的区块链网络财团中的其他人可以类似地创建记录（并防止与您网络中的其他人发生冲突），那么您的密钥形成就可以了，因为密钥/记录的共同性将提交到分类账中的其他组织/实体在同一区块链网络中。
从您的问题来看，您似乎有一个合同（资产）和可授权的小部件（资产）。
您的合同资产（复合）密钥看起来不错-大多数都与唯一性有关，并且可以增长。该资产是由（例如）createContract交易创建的。
您的窗口小部件资产密钥看起来不错（例如，刚刚创建的资产，尚无被许可人），因为密钥组合在网络中是唯一的-这是由“可用”交易创建的。最初的许可状态为“无” ..等。
最后，“许可”交易可以更新现有的小部件（在trxn中使用被许可人参数-“被许可人”是“小部件”的属性（如果有多个被许可人，则为数组），并绑定到相同的许可人/ widgetId键）。第一个被许可人将小部件的状态更新为“已许可”（而不是“无”等）
关于“付款”交易，没有足够的信息：但是您需要问，正在更新什么资产（它是否存在-它的资产密钥是什么）以及将应用的交易参数是什么资产（或其他资产，如果工作单位更新为“倍数”）-顺便说一句，您的意思是“ ContactNum / Licensee”吗？无论如何，值得深思。