Earlier quoted context omitted.
Mostly it involves people making systems that are too complex to trivially analyze. You can not write arbitrarily complex secure code. You need to limit your scope and do one very simple thing extremely tersely and correctly. You can make powerful systems with simple correct independent components. You can not make complex secure monolithic systems. It gets even worse when you look at contracts with delegation. The p…
Yes, I agree. Most of the security of smart contracts should be in the VM. Things like self-asserting the results and only finishing the transaction if it actually passes a double-check. Or set value limits to each smart-contract (so even if there's a bug it will only operate on 0.00001 BTC for example).
The key is that the contracts need to be minimal and analyzable, so its ~100 lines of code you can manually analyze. Documented separately all the edge cases, or ideally removed through good design so they simply don't exist. A bunch of problems I've seen in the real world of crypto are annoying edge cases that you can fix with an if statement, or ideally change the design to remove them completely. It's actually a surprisingly hard space because you're trying to make terse, complete and secure code.
In normal web/systems programming you have layers of security; internal services, external services, firewalls, access controls, vpns, security by obscurity, etc etc etc. In crypto you have none of that. Everything is 100% public, the code probably should be published, or else it is trivially decompiled. If there is a problem someone will find it if there is value in finding it.