# FastSSZ - Struct Tags vs. Protoreflect

## Summary
At Prysmatic Labs we have been using [gogoproto](https://github.com/gogo/protobuf) to generate proto messages in golang to implement the APIs into Prysm. However, gogoproto has been problematic to set up and maintain.
Recently, golang has released the [protobuf V2 APIs](https://blog.golang.org/protobuf-apiv2) which allow for native protobuf extensions to be read using protoreflect. We are exploring replacing gogoproto with these new APIs in order to make our APIs simpler to use, and make use of exclusively the native protobuf API.
However, changing the way tags are written means we need to change our [fastssz](https://github.com/ferranbt/fastssz) library as well to use native protobufs over the struct tags that gogoproto would add.
This document is to outline the benefits of changing fastssz to use the native APIs, to help discern if we should make the changes, or take the easy workaround route.

## Available Approaches
### Write a protoc plugin to append the protobuf extensions as struct tags (easy way)
Pros:
- Easiest route
- Requires no changes to fastssz
- Could serve as a way to unblock temporarily

Cons:
- Another plugin (on top of go-cast) to maintain
- Accrues technical debt

### Change fastssz to use protoreflect (hard way)
Pros:
- Fastssz itself would use entirely native APIs, no AST or gogoproto reliance
- Using protoreflect may be faster and cleaner
- Prysm APIs would only require the go-cast extension

Cons:
- Additional work (rewrite of fastssz essentially)