🐙 Prysm Codebase Community Feedback Tracking 🐙

[rauljordan]

💎 Tracking Issue

Background

Yesterday, we ran a survey specifically targeting the Prysm community and contributors to let us know how they feel about the project. We received some high quality submissions and had a section where users could tell us how they feel about the docs. Here are the paraphrased, actionable responses:

🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙🐙

• Integrating any Prysm component into a Go module project is difficult/impossible due to bazel. Part of getting started with contributing is to take some subset and extend it your way, which is not really possible right now. Refactor dependencies, make Prysm "go gettable" #6053
• Documenting the relations between the many features/parts of the codebase helps someone who wants to get involved
• Remove the WebSocket subscription requirement for ETH1 nodes
• Reduce configuration complexity, we constantly fetch BeaconConfig() over and over
• Align naming of rewards/penalties functions closer to spec, functions such as "ApplyToEveryValidator" seem convoluted
• Things like "ApplyToEveryValidator" seem convoluted
• A single point of truth for some client/chain/config/etc. abstraction would be beneficial, as it is very confusing to use all the globals we currently have and various interfaces. The blockchain package needs to be much simpler and have fewer interfaces.
• RPC/protobufs which were creating more difficulties for others debugging their client than it helped any kind of efficiency or tooling, we should be exposing the http gateway by default
• The ethdo project is wallet-centric instead of keyfile-centric, which is a source of friction that other client teams are trying to avoid. We should aim for more standardization on that front. Will be resolved by Prysm Validator Accounts Revamp Tracking #6220
• Trace logging is messy (fast, spammy, unformatted), log-topics would be very useful to make more sense of certain features without wading through a stream of trace logs
• Slasher needs clear documentation and architectural overview
• Clear, command line interfaces to deploy more than one validator and make deposits would be appreciated

Plans

Next step is to look into which of these items we want to tackle and open required issues or PRs to resolve them as needed. Some of these can be their own tracking issues.

[terencechain]

I'll take on The blockchain package needs to be much simpler and have fewer interfaces.

[rauljordan]

This one is more of a list of generic problems which do not have clear, actionable PRs as resolutions compared to other open issues. Instead, this will be fixed by a combination of #6534, improving our logging, and adding documentation for items such as slasher. It is also related to #7514