为什么 Hyperledger fabric 使用 protobuf 而不是 JSON?

Why does Hyperledger fabric use protobuf instead of JSON?

protobuf 提供了哪些 JSON 不能提供的优势?

"protobuff 比 JSON 快" - 这是什么意思?

注意:我知道 protobuf 和 JSON 之间的区别。

Fabric 节点使用 gRPC 进行通信,因此,它使用 protobuf 数据序列化。

在 Fabric 中,通过线路发送的数据不需要人类可读,因为无论如何数据都是在没有人工干预的情况下构建的。

当你有预期由用户构建的有效负载时,你通常使用 JSON,例如 REST API 足够简单,用户可以与 curl/wget/scripts 一起使用,或者当您希望能够调试通过线路发送的数据时。

正如@jpa 在他的评论中指出的那样,发送 JSON 有其缺点,例如将数据方案本身与每条消息一起发送以及实际数据,并且与仅发送数据的 protobuf 相比效率低下仅且数据方案未通过网络发送。

但是使用 protobuf 也有一个缺点,那就是 protobuf 序列化不是确定性的。

在 Fabric 等到处都有签名检查的系统中,如果您通过消息发送签名,则消息必须作为字节块发送。

这使得 Fabric 交易结构效率极低,因为它包含嵌套的消息封装,因为每个“层”在其上方的层中表示为不透明的字节块,并且访问交易消息的内部字段需要将字节块解组为实际的消息对象。

这使得 Fabric 事务处理非常缓慢,正如 observed in a paper 几年前:

Fabric uses gRPC for communication between nodes in the network. To prepare data for transmission, Protocol Buffers are used for serialization. To be able to deal with application and software upgrades over time, Fabric’s block structure is highly layered, where each layer is marshaled and unmarshaled separately. This leads to a vast amount of memory allocated to convert byte arrays into data structures.

如果 Fabric 事务消息传递基于确定性编组方案(例如 ASN1),那么您将能够在没有中间不透明字节 blob 的情况下发送事务,因为签名检查将涉及通过确定性 ASN1 序列化消息序列化以获取 Fabric 消息携带的字节块。