Even with a corruption alarm, an inconsistent etcd member can serve corrupted data to clients between the time of boot and detection. This is undesirable in cases where corruption can't be tolerated (e.g., serving disk geometry data). Worse, if the corruption is on a leader, it's possible it will further propagate the corruption by sending snapshots to other members.

Instead, if a member can contact the client addresses of its peers, it should first fetch hashes from the other members at a known revision and compare before serving any client requests. If the hashes don't match, the server will print a fatal and terminate. This will stop etcd from initializing with inconsistent data in most cases.

Related: #8214