Content pfp
Content
@
0 reply
0 recast
2 reactions

Cate pfp
Cate
@cate
I've been trying to understand why doesn't EVM work based on parallel execution, like SVM, and why aren't there discussions around this as an endgame. Now questioning even more after hearing this great podcast https://www.youtube.com/watch?v=fbppZY8V0LI&t=130s
2 replies
0 recast
2 reactions

haurog pfp
haurog
@haurog.eth
In the podcast they made it pretty clear that parallelization of the transaction execution is not the bottleneck for Ethereum. State size and state retrieval is a bigger issue which needs to be solved first. Solutions are verkle trees and state expiration. Parallelized EVM is in the works by Polygon, NodeReal and Sei.
1 reply
0 recast
2 reactions

Cate pfp
Cate
@cate
But isn't this state size and retrieval issue an existing problem for every chain, including Solana? Honest question.
2 replies
0 recast
1 reaction

haurog pfp
haurog
@haurog.eth
Yes, my understanding as well. AFAIK, solana keeps state (all of it?) in RAM. Makes state access faster and pushing out the bottleneck. Solana node needs about 512 GB RAM vs 16 GB for an Ethereum node.
1 reply
0 recast
1 reaction

Cate pfp
Cate
@cate
The reliance on large RAM for state storage doesn't inherently solve the state growth problem; it merely shifts the bottleneck. As the state size grows, the cost and feasibility of maintaining such high-memory nodes escalate. In Ethereum, the introduction of stateless clients will reduce the burden on nodes.
1 reply
0 recast
1 reaction

Cate pfp
Cate
@cate
However, my question remains. Even if the issues you were mentioning are fixed in the short term, parallel processing allows to distribute the computational load more effectively across multiple cores and threads, and I was trying to understand why this is not the primary focus for Ethereum.
2 replies
0 recast
1 reaction

haurog pfp
haurog
@haurog.eth
Just to add: Node clients are generally already quite well parallelized. Nethermind and Lighthouse regularly use 3-5 cores in parallel during peaks on my node. The additional gain from parallel transaction execution is definitely there, but not that huge.
1 reply
0 recast
1 reaction

haurog pfp
haurog
@haurog.eth
Yes, parallel transaction execution is good when you have really solved earlier bottlenecks. Transaction execution takes around 300 ms on my node. Parallelization would bring that down to 200 ms, maybe 150 ms. Not a big difference considering a 12 s block time. Definitely needed, but not a pressing issue.
0 reply
0 recast
1 reaction