> How is it lazy and herd-like to _not_ run the latest and greatest?
I'm not sure what you're asking here. Ethereum incentives don't make you run the latest version of your client's software (unless there's a hardfork you need to support). You can run any version that follows the network consensus rules.
The incentives are there to punish people who use the most common software. For example, let's say there are around 5 consensus clients which are each developed by independent teams. If everyone ran the same client, a bug could take down the entire network. If each of those 5 clients were used to run 20% of the network, then a bug in any one of them wouldn't be a problem for Ethereum users and the network would keep running.
If the network is evenly split across those 5 clients but all of them are running in AWS, then that still leaves AWS as a sigle point of failure.
The incentives baked into the consensus protocol exist to push people towards using a validator client that isn't used by the majority of other validators. That same logic applies to other things like physical host locations, 3rd party hosting providers, network providers, operating systems, etc... You never want to use the same dependencies as the majority of other validators. If you do and a wide-spread issue happens, you're setting yourself up to lose a lot of money.
It sounds like you're describing the advantages of diversity, with a little game theory thrown in to sweeten the deal. Still not sure how that can be described as lazy, or did I completely mis-read the original phrasing?
I'm not sure what you're asking here. Ethereum incentives don't make you run the latest version of your client's software (unless there's a hardfork you need to support). You can run any version that follows the network consensus rules.
The incentives are there to punish people who use the most common software. For example, let's say there are around 5 consensus clients which are each developed by independent teams. If everyone ran the same client, a bug could take down the entire network. If each of those 5 clients were used to run 20% of the network, then a bug in any one of them wouldn't be a problem for Ethereum users and the network would keep running.
If the network is evenly split across those 5 clients but all of them are running in AWS, then that still leaves AWS as a sigle point of failure.
The incentives baked into the consensus protocol exist to push people towards using a validator client that isn't used by the majority of other validators. That same logic applies to other things like physical host locations, 3rd party hosting providers, network providers, operating systems, etc... You never want to use the same dependencies as the majority of other validators. If you do and a wide-spread issue happens, you're setting yourself up to lose a lot of money.