Introduction/Contributing

Lacks a link to the repository. Would be good to have a hyperlink to the actual repo to make it easier for contributors.

Ethereum 2.0 is shown on the sidebar, it should just be Ethereum.
Would like to drop all mentions of eth1 and eth2. Just stick to consensus/execution when referring to the two layers.
Give examples of all the CL and EL clients.
Link to See also link https://github.com/gateway-fm/validator-kb/blob/main/reference/basics/nodes/README.md does not work.

Instead of grouping it by Nodes I would group them by clients, i.e call the field clients.
Have different tabs for each client with their corresponding configuration and checkpoint sync args.
Also instead of dropping links of how to do checkpoint sync, actually use an example with the link pointing to further instructions.
samcm/checkpointz has been moved => ethpandaops/checkpointz.

Instead of snapshotting, It would make more sense for solo validators to know about pruning e.g https://geth.ethereum.org/docs/fundamentals/pruning

links don’t work
“If it goes all the way to 16 ETH, it will be ejected from the set and it will not be able to re-join again.” need to be rephrased.
The content is really difficult to follow here, it needs to be simplified.

link a list of currently available mev boost relayers
There’s no real info about mev-boost. PBS is an ongoing research topic and doesn’t need to be mentioned here. It would be nice to see a pro/con document about mev and why to/not to run mev boost.

Needs a lot more information about how the staking workflow goes along with what the implications are

https://docs.gateway.fm/apis/ethereum/eth_getblockbynumber Api documentation should have CamelCase instead of all lowercase letters.
some links don’t work.
Add docs for monitoring node health on CL as well
Add info on what metrics to watch for and when a node could need help

Would like to see a breakdown for hw requirements per client. E.g EL requires x amoung of ram/storage/cpu, CL requires x amount of ram/storage/cpu and validator really don’t need much.
" NVMe are more expensive and unless you want to push the node to its limits, they make very little difference." this isn’t really valid advice and we’d rather stick to presenting users data and allowing them to make their decisions. i.e, specify throughput needed and let users choose if they want SSD/NVMe
Network, 100mbps isn’t really a good recommendation for anyone except big node operators. One can run a node in under 5mbps if tuned correctly. So i’d rather specify a peer size that is reasonable, i.e 20/50/100 and specify the bandwidth limits for them all.
“The more peers you have, the higher will be traffic, but the more chances will be that your attestations will be included in time, and ultimately, that leads to more rewards.” Its not that straightforward. You don’t need 200 node connection to maximize your profits. Anything above 25-50 is diminishing returns actually. More peer connections will help with accelerated gossip though.
“It is not recommended to go below 16Ghz for every piece of the setup: CL, EL, Validator Client.”, I think there needs to be more context and a correction to the 16GHz number.

General feedback

I would stay away from using light green as the hyperlink color, as its rather hard to see on white background. Either change the background or change the hyperlink color or add an underline.
The doc fails to describe who the target audience of the doc is and why they should read it and what they could aim to learn from it