No, it has nothing to do with the presence of the unsafe blocks. Rust would be exactly as safe or unsafe as it currently is if the requirement to wrap unsafe operations in unsafe blocks were removed. The only difference would be that it would be more difficult to grep for code that used those operations.
Yes, one bad unsafe block in rust can screw up even safe code, everybody here understands that. The difference is that the potential problem surface is much smaller and it is obvious where it might be.
And by limiting the attack surface the language becomes safer. Not formally, but in practice.
How small the potential problem is depends purely on how much unsafe code you write, regardless of whether it has a special keyword associated with it.
You can imagine though, that the intended model for rust programming is to avoid "unsafe" as much as necessary. Essentially that C++ is using unsafe by default, while rust has safe by default.
You have to go out of your way not to stay in safe for the most part (if rust's design does what they intended), which implies that most of your code should be provably safe (by rust's definition of safe), as long as the ideally small unsafe blocks are correct, if the program compiles.
Where in C++, there is no such gaurantee regarding compilation; even your "safe" code isn't shown to be safe by the compiler (additional tooling may apply further checks); your whole codebase is assumed to be unsafe.
The "potential problem" is naturally the size of your codebase, whereas rust offers it as a subset of the codebase.
