Hyperledger fabric 在fabric gatway中调用评估后提交：从fabric SDK迁移到fabric Gaetway

我正在尝试将代码从Fabric SDK迁移到Fabric Gaetway。目前，为了发送事务，我构造了TransactionProposalRequest对象，并使用channel.sendTransactionProposal方法将其发送到fabric。作为响应，我获取TransactionProposalResponse的集合，然后检查其中50%是否成功，如果成功，我将继续并将事务提交给订购方

现在，当我使用fabric gateway迁移到高级API时，我看到了两种方法“evaluateTransaction”和“submitTransaction”，第一种方法只是发送给对等方收集背书，而不将其提交给订购方。第二种方法是先收集背书，然后将其提交给订购方，然后将其保存到分类账中

我的要求是

为了能够首先检查背书回复，如果其中50%是成功回复，则继续将其提交给订购方

如何使用新的API实现这一点？如果我首先调用“evaluateTransaction”方法并检查响应，然后调用“submitTransaction”，如果这是我所期望的方式，那么它最终会对同一事务进行两次背书，因为submit也会在内部首先收集背书

---

任何关于这方面的建议都会有所帮助

如果您使用发现，则submitTransaction将仅联系足够的对等方进行模拟，以满足您的认可策略。如果无法联系任何同行，则应尝试从同一组织中的其他同行处获得背书，以便收集足够的背书，以满足您的背书政策，从而能够提交给订购方

---

因此，使用discovery，您不必再担心检查50%的响应。

谢谢您的回复。当我在网上阅读时，我了解到背书政策会说一些类似的话，许多同侪应该签署交易以表明其有效，或者至少该同侪必须签署等。我的要求是获得同侪的响应，从谁处获取并检查提案响应中返回的成功代码无关紧要。如果它与某些预定义代码匹配，则视为成功。因此，我首先需要获取提案响应集合，并检查其中返回的代码，以将其声明为成功或失败。这可能吗？如果不清楚，一定要告诉我。渠道认可政策是在组织层面，而不是同行层面，因此可能会有所帮助，不确定网关api如何适用于您的场景。是的，我理解。这就是我计划首先调用evaluate api的原因，它只评估并返回提案响应，而不实际提交到分类账。然后在检查返回的提案响应后，我可以继续使用submit api将其保存到分类账中。我唯一关心的是，由于这两个api都会在内部调用代码以获得已签名的提案（背书），因此，当我们将同一事务传递给这两个api进行背书时，此流程是否有效。我认为您有两个选择，重新设计网络/链码以匹配网关api范型，在该范型中，网络/链码仅从足够多的认可对等方处获得认可，并且所有对等方都应同意，或者不使用网关api并坚持使用结构客户端实现。就我个人而言，我希望您的网络和应用程序能够在结构设计以及网关api中工作。