github.com/pokt-network/tendermint@v0.32.11-0.20230426215212-59310158d3e9/docs/architecture/adr-055-protobuf-design.md (about)

     1  # ADR 055: Protobuf Design
     2  
     3  ## Changelog
     4  
     5  - 2020-4-15: Created (@marbar3778)
     6  
     7  ## Context
     8  
     9  Currently we use [go-amino](https://github.com/tendermint/go-amino) throughout Tendermint. Amino is not being maintained anymore (April 15, 2020) by the Tendermint team and has been found to have issues:
    10  
    11  - https://github.com/tendermint/go-amino/issues/286
    12  - https://github.com/tendermint/go-amino/issues/230
    13  - https://github.com/tendermint/go-amino/issues/121
    14  
    15  These are a few of the known issues that users could run into.
    16  
    17  Amino enables quick prototyping and development of features. While this is nice, amino does not provide the performance and developer convenience that is expected. For Tendermint to see wider adoption as a BFT protocol engine a transition to an adopted encoding format is needed. Below are some possible options that can be explored.
    18  
    19  There are a few options to pick from:
    20  
    21  - `Protobuf`: Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. It is supported in countless languages and has been proven in production for many years.
    22  
    23  - `FlatBuffers`: FlatBuffers is an efficient cross platform serialization library. Flatbuffers are more efficient than Protobuf due to the fast that there is no parsing/unpacking to a second representation. FlatBuffers has been tested and used in production but is not widely adopted.
    24  
    25  - `CapnProto`: Cap’n Proto is an insanely fast data interchange format and capability-based RPC system. Cap'n Proto does not have a encoding/decoding step. It has not seen wide adoption throughout the industry.
    26  
    27  - @erikgrinaker - https://github.com/tendermint/tendermint/pull/4623#discussion_r401163501
    28    ```
    29    Cap'n'Proto is awesome. It was written by one of the original Protobuf developers to fix some of its issues, and supports e.g. random access to process huge messages without loading them into memory and an (opt-in) canonical form which would be very useful when determinism is needed (e.g. in the state machine). That said, I suspect Protobuf is the better choice due to wider adoption, although it makes me kind of sad since Cap'n'Proto is technically better.
    30    ```
    31  
    32  ## Decision
    33  
    34  Transition Tendermint to Protobuf because of its performance and tooling. The Ecosystem behind Protobuf is vast and has outstanding [support for many languages](https://developers.google.com/protocol-buffers/docs/tutorials).
    35  
    36  We will be making this possible by keeping the current types in there current form (handwritten) and creating a `/proto` directory in which all the `.proto` files will live. Where encoding is needed, on disk and over the wire, we will call util functions that will transition the types from handwritten go types to protobuf generated types.
    37  
    38  By going with this design we will enable future changes to types and allow for a more modular codebase.
    39  
    40  ## Status
    41  
    42  Proposed
    43  
    44  ## Consequences
    45  
    46  ### Positive
    47  
    48  - Allows for modular types in the future
    49  - Less refactoring
    50  - Allows the proto files to be pulled into the spec repo in the future.
    51  - Performance
    52  - Tooling & support in multiple languages
    53  
    54  ### Negative
    55  
    56  - When a developer is updating a type they need to make sure to update the proto type as well
    57  
    58  ### Neutral
    59  
    60  ## References