cosmos/ibc

Use Protobuf encoding instead of JSON for the ICS20-v2 `FungibleTokenPacketData`

womensrights opened this issue · 6 comments

womensrights commented

The encoding type used for the FungibleTokenPacketData and FungibleTokenPacketAcknowledgement in the current ICS-20 spec is JSON. There have been some suggestions to use protobuf based encoding instead which I am personally on board with. Some of the reasons for the change are detailed below and is intended to open up the discussion for the choice of encoding for ICS-20 v2:

Advantages of using protobuf over json

  • Performance enhancements: protobuf uses binary encoding compared to json's text based encoding which reduces the message sizes and protobuf is supposedly more efficient, particularly relevant for applications in gas constrained environments, e.g. within the EVM
  • Stronger Typing of data: By having a clear schema definition in the schema file, the data sent with the application can be validated and the schema can be enforced
  • Backwards and Forwards Compatibility: if new fields need to be added or removed over time, there is more flexibility to do this with protobuf, and this is particularly relevant for using ICS-20 in combination with executable middleware

Disadvantages of using protobuf over json

  • Human Readability: json is in a human readable format which appears to have been the main motivation for historically using this encoding format
  • Overhead of managing schemas: perhaps there is a greater overhead of managing the protobuf schemas and could result in reduce flexibility.
womensrights commented

Some additional useful context is also detailed in this write up.

The main argument is that json is too expensive in EVM environments and for ZK based applications

zmanian commented

One question in my mind is how IBC can more intentionally address the demand for alternative serialization in ICS-20.

There is a considerable amount of demand for Ethereum 's ABI encoding and Borsh for Near/solana.

One way might be to define ICS-20 v2 as a family of similar protocols each with its own serialization.

  • 👍1
nicolaslara commented

One question in my mind is how IBC can more intentionally address the demand for alternative serialization in ICS-20.

This sounds like a good idea, but probably something that should live one level up. Maybe the Packet itself could have an optional field specifying the serialization format of the data.

  • 👍3
bluele commented

Maybe the Packet itself could have an optional field specifying the serialization format of the data.

I think it makes sense to use ChannelEnd's version to determine which packet encoding method during Channel handshake. This prevents the receiving of packets with encoding that is not supported by the chain.

Looks like this idea is also described in https://github.com/cosmos/ibc/tree/main/spec/core/ics-004-channel-and-packet-semantics#definitions.

The version string stores an opaque channel version, which is agreed upon during the handshake. This can determine module-level configuration such as which packet encoding is used for the channel.

crodriguezvega commented

Thank y'all for the feedback. We will go ahead with this proposal for now and use protobuf encoding in ICS20 v2. However, we envision a not so distant future where we should be able to have an ICS04 packet that contains enough information to explain the type and the encoding of the application packet data.

crodriguezvega commented

Closed by #1118