Insights +评估gRPC消息流Hyperledger Fabric

Question

我想检查从调用智能合约到创建一个块的gRPC消息流：

我确切地想检查这些步骤（使用的消息流），我后来发现它们组成了一个完整的块（如果我理解正确的话，这些部分仅在某些添加的块的末尾放在一起）：

调用链码的调用，例如使用CLI将“ a”的值更改为“ 10”：

 1. CLI sends Proposal to Endorser -> [SignedProposal with Signature, Proposal:(Header+Payload)]

 2. Endorser sends Proposal Response back to CLI -> [ProposalResponse with its Endorsement,
    PropRespPayload] 

 3. CLI packs endorsements into Transaction + sends them to orderer for block creation

 4. Block is created by orderer + validation of sign.

最快的获取方法是什么？

我做了什么：

1. （[不好，很费力）尝试修改二进制代码（例如处理gRPC的“对等”）中的代码，然后重建图像：

我的问题是，我能够像对等可执行文件一样构建和修改二进制文件（用于映像中，并像对等文件一样在docker容器内启动），但是我最终想要使用它们并使我们成为示例项目像“第一网络”一样，在这里我可以调用事务并使用自己的实现进行日志记录，那里是gRPC。我在这里可以做的并且很耗时的是重建所有图像，然后使所有示例文件适合新环境并实现这部分，但是我认为必须有一种更快的方法来评估消息流（使用完整gRPC消息流的输出（已解码和编码）。

2. （[我认为是目前最好的方法）：我还没有发现更快的方法（Go和gRPC的新功能），而不是通过Wireshark记录gRPC发送的内容并尝试对其进行解码（但是它不适用于所有部分，导致消息不完整或令人恐惧）。对于某些部分（证明符号），必须具有某些对象的编组版本。这实际上是我最需要的，因此，我需要了解接线部位的gRPC内容：）

您对我有什么建议吗？您愿意继续使用Way1还是Way2？还是我采用的解决方法过于复杂？

是否存在更快的方法？我的意思是我需要未编组的部分，但也需要一些对象的编组的内容，并且我有原始文件（当这些文件是我在进行调用时在wireshark中记录的日志部分的正确文件时）。

Answer 1

这似乎与question you posted a month or so ago密切相关。

正如您所指出的，如果您希望执行诸如验证签名之类的操作，则将需要邮件的已编组形式，但是，如果您希望检查邮件，则需要将其解组。

我认为选项1（修改代码以转储您所需的信息）仍然是最有用的。因为您可以在代码本身内部执行任何序列化，持久性或分析。如果您只是通过诸如wire-shark之​​类的东西将这些数据结构存储到磁盘上，那么您将需要跟踪它们，解析它们等等，这对我来说似乎是更多的工作。

[如果您在磁盘上封送了邮件，则您可以尝试使用configtxlator之类的工具将邮件解组为更友好的JSON格式（如果您已经跟踪了适当的类型，尽管这似乎比简单地注入代码要困难得多）我。

Answer 2

您可以按照以下简单步骤制作自己的gRPC api：

• 首先，您需要提出签名的建议。要提出签名的建议，您可以从endorser_test.go file中获得想法。
• 要将签名的提案发送给对等方进行背书，您需要一个ProcessProposal gRPC调用，您可以在其中获取背书对等方的响应，也需要创建EndorserClient。
• 此后，您需要收集同行的所有背书，并必须签署签名的信封
• 要制作签名的信封，可以从txutils.go文件中寻求帮助
• 要将签名的信封发送给订购者，您需要通过发送gRPC呼叫将信封广播给订购者，我们需要在其中创建AtomicBroadcastClient。