EIP 3074’s all or nothing, trust-maximizing security model pulls towards permissioned innovation because it requires a tremendous amount of trust capital to play. Permissioned innovation is the consequence we should expect, because in practice, devs outside a very limited set of players won’t be able to use this. It’s great for Metamask’s ability to innovate, not so great for dapp devs. Should we pretend the protocol exists in a vacuum? You yourself are now advocating whitelisting invokers, losing some vocal supporters in the process. I agree that nothing else makes sense. If whitelisting isn’t the standard best practice straight out the gate it soon will be after an onslaught of scams. Trust minimized security models (eg 4337 paymasters) level the playing field for a much wider range of devs.
I don’t think anyone is seriously advocating implementing complex accounting features in the protocol. 4337 already works without ANY protocol changes. Having some protocol changes will help in the future with efficiency, but even without them full 4337 style account abstraction is already more powerful than EIP 3074 EOAs. What is more relevant is that enshrining EOAs will likely delay Ethereum’s full account abstraction roadmap by creating a less powerful half measure. This will reduce the sense of urgency in developing account abstraction. We’re more likely to get stuck on a local maxima.
Apologies if I am misunderstanding you, but you seriously suggesting that the environment in which the EVM operates is less adversarial than Linux’s? Every bit code on the EVM is transparent. All of its attack surface, every method is immediately exposed. No firewalls. If you exploit it, there’s money at stake. Sudo on Unix systems gave us an endless parade of security headaches even when Unix was still running inside friendly academic networks. As soon as the environment got more adversarial we had to throw it out “all or nothing” as a reasonable security design and replace it with capabilities and mandatory access control mechanisms like RBAC. If sudo isn’t good enough for a Linux server on the Internet, how can it be good enough for EVM account security?
It is much safer to rely on a good trust-minimized security design than rely on a vaporware ecosystem of formally verified contracts. If formal verification were so easy, all the major on-chains contracts would be formally verified. That doesn’t seem to be the case. Besides, formal verification is no panacea. Even if you formally verify the implementation, there’s no way to formally verify the spec for the formal verification process. In practice, EIP 3074’s trust maximized model is going to get us a very limited set of very powerful, non formally verified invokers that support features as as intents.