Miden chooses to be incompatible with EVM, fundamentally due to architectural design considerations — not targeting EVM itself.
The key difference lies here: Miden moves execution logic from the chain to the user side, with state data stored off-chain, only sending proofs to the chain for verification.
Comparing this with the EVM approach reveals the difference. EVM handles both verification and execution on-chain, with each node running the logic. These two architectural philosophies are completely different — one relies on the user to perform computations and the chain to verify results, while the other involves the entire network jointly verifying.
This is not an ideological dispute; it’s purely a trade-off between efficiency and scalability. Different design goals correspond to different technical choices.
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
10 Likes
Reward
10
6
Repost
Share
Comment
0/400
GasFeeTherapist
· 5h ago
Alright, I understand this logic, but the question is, are users really willing to run proofs themselves?
---
It's another architecture design... Basically, it's a matter of different bets; whoever can run through it first is the winner.
---
Proofs on user side sound great, but what if the cost of generating proofs is more expensive than on-chain verification?
---
I just want to know if Miden's user experience will be better than EVM. Don't just talk about technical vision.
---
This idea is actually a bit like the rollup approach? Anyway, it's all about moving off-chain.
---
Skipping the step of EVM compatibility is a big mistake; the ecosystem won't grow if you do that, bro.
---
Wait, how do we ensure the off-chain state isn't tampered with? Feels like a new pitfall.
View OriginalReply0
ILCollector
· 01-05 18:33
Why does it feel like the blame is being shifted to the architecture design... Basically, it just doesn't want to be compatible with EVM. Transferring computing power to the user side sounds easier, but will this compromise the user experience?
View OriginalReply0
CantAffordPancake
· 01-04 16:52
Well, I understand this logic. To put it simply, it's just a different way of distributing computing power.
Incompatibility with EVM isn't a big problem; the key is whether Miden's proof mechanism is reliable.
Running calculations locally on the user's side indeed reduces on-chain pressure, but what if there's a vulnerability in the proof...
The EVM approach, although redundant, at least ensures the entire network verifies it once, which is reassuring.
If the Miden approach really works and becomes successful, it would be impressive. But I'm worried about potential issues popping up along the way.
View OriginalReply0
GateUser-0717ab66
· 01-04 16:50
Damn, now I finally understand what true architectural innovation means. It's not necessary to be compatible with EVM to survive.
But on the other hand, user computing power bears a heavy load... Can this really be popularized?
Miden's approach is a bit ruthless, saving a lot of trouble, but what about user experience?
Even if there's no problem in theory, there are still risks in actual implementation.
It feels like betting on the ZK proof set to run smoothly in the end—it's a bit risky to bet on that.
I understand the overall idea, but how to create network effects...
Ultimately, it still depends on whether the ecosystem can take off. No matter how elegant the architecture design is, it's useless.
Whether or not to be compatible with EVM isn't really the core issue; being usable is the key.
I really want to see if Miden can succeed in the end... It's still a bit uncertain at the moment.
View OriginalReply0
GateUser-e87b21ee
· 01-04 16:47
Damn, it's that ZK proof approach again. To put it nicely, it's just passing the work to users to compute themselves, while the chain is only responsible for verification. But thinking about it carefully, this is indeed completely different from the way EVM runs duplicate logic across a bunch of nodes.
View OriginalReply0
GateUser-74b10196
· 01-04 16:35
Wow, finally someone has clarified this issue. It's not that EVM is not good enough; it's just that the two approaches are fundamentally opposite.
Bro, your argument is excellent—user-side computing power vs. full network validation. The difference is at the infrastructure level.
Damn, I finally don't have to look at those black-and-white debates anymore.
Miden's approach is indeed impressive—outsourcing computation and verifying on-chain. This is true scalability thinking.
But the question is, how secure is the user's side computation?
That's why Miden absolutely refuses to rely on EVM. They are fundamentally two completely different logics.
I just want to know how fast this system can really go once it goes live.
Forget it, it's not that complicated. It's just a different choice between computing power and validation.
Miden chooses to be incompatible with EVM, fundamentally due to architectural design considerations — not targeting EVM itself.
The key difference lies here: Miden moves execution logic from the chain to the user side, with state data stored off-chain, only sending proofs to the chain for verification.
Comparing this with the EVM approach reveals the difference. EVM handles both verification and execution on-chain, with each node running the logic. These two architectural philosophies are completely different — one relies on the user to perform computations and the chain to verify results, while the other involves the entire network jointly verifying.
This is not an ideological dispute; it’s purely a trade-off between efficiency and scalability. Different design goals correspond to different technical choices.