Fabric 节点使用 gRPC 进行通信,因此,它使用 protobuf 数据序列化。
在 Fabric 中,无需人工读取通过网络发送的数据,因为无论如何数据都是在没有人工干预的情况下构建的。
当您拥有预期由用户构建的有效负载(例如 REST API)时,您通常使用 JSON通过网络发送的数据。
正如@jpa 在他的评论中指出的那样,发送 JSON 有其缺点,例如将数据方案本身与每条消息以及实际数据一起发送,并且与仅发送数据的 protobuf 相比效率低下,数据方案是不是通过网络发送的。
但是使用 protobuf 也有一个缺点,那就是 - protobuf 序列化不是确定性的。
在像 Fabric 这样到处都有签名检查的系统中,如果您通过消息发送签名,则消息必须以字节块的形式发送。
这使得 Fabric 事务结构效率极低,因为它包含消息的嵌套封装,因为每个“层”在其上方的层中都表示为不透明的字节块,并且要访问需要解组的事务消息的内部字段将字节块放入实际的消息对象中。
这使得 Fabric 事务处理非常缓慢,就像几年前的 observed in a paper:
Fabric 使用 gRPC 在网络中的节点之间进行通信。到
准备传输数据,Protocol Buffers 用于
序列化。能够处理应用程序和软件
随着时间的推移升级,Fabric 的块结构是高度分层的,其中
每一层都是单独编组和解组的。这导致一个
分配大量内存以将字节数组转换为数据
结构。
如果 Fabric 事务消息传递基于 ASN1 等确定性编组方案,那么您将能够在没有中间不透明字节 blob 的情况下发送事务,因为签名检查将涉及通过确定性 ASN1 序列化将消息序列化为获取 Fabric 消息携带的字节块。