개인적으로 생각하는 비하인드 스토리를 풀자면, 각 찬반 의견에는 꽤 재미있는 이해관계가 있는 것으로 보입니다.

개인적으로 생각하는 비하인드 스토리를 풀자면, 각 찬반 의견에는 꽤 재미있는 이해관계가 있는 것으로 보입니다. 패러다임/템포 패러다임/템포가 프레임 트랜잭션에 반대하는 이유는, EIP-8141이 템포의 아키텍처와는 완전 반대의 구조이기 때문입니다. 허나 템포는 EVM이므로 이를 도입해야 하며, 이는 템포에서 쓰이지 않는 dead code를 노드에 넣어야 하는 것과 같습니다. 만약 넣지 않는다고 결정하면, EVM 동등성을 포기해야 하죠. 물론 패러다임의 주장은 viem / wagmi / Foundry 등 개발자 툴링을 수년 간 빌딩해온 경험에서 나온 거라, 아예 틀렸다고 보긴 어렵습니다. 템포 트랜잭션도 Porto라는 스마트 어카운트를 빌딩한 경험을 녹여 잘 만들어진 구조라고 볼 수 있구요. 모나드 모나드는 더욱 상황이 심각할 수 있는게, EIP-8141을 지원하면 모나드의 아키텍처 자체가 깨질 수 있습니다. 모나드는 트랜잭션 실행과 합의가 분리되어, 합의를 먼저 하고 실행을 하는 수순을 밟는데, EIP-8141은 '트랜잭션의 유효성이 다이나믹하게 변할 수 있는' 구조라 트랜잭션 데이터만 보고 유효성을 판단할 수 없습니다. 즉, EIP-8141은 노드가 트랜잭션을 합의 전 무조건 한번은 실행해야만 하도록 만듭니다. 이더리움은 이를 멤풀 유효성 규칙 및 향후 zkEVM 전환을 통해 해결할 수 있을 걸로 보이며, L2는 공개 멤풀이 아니니 블록 전파 전 엄격한 실행이 요구되지 않아 괜찮지만, 공개 멤풀에 '합의와 실행 분리'를 메인 확장성 메커니즘으로 가져가는 모나드에게는 크리티컬해 보입니다. 두 케이스 모두 alt L1임에도 EVM을 택해, 종속성 이슈가 발생한 것에 해당합니다. 각자만의 VM을 만드는 것과 기존 VM을 그대로 따르는 것의 트레이드오프로도 볼 수 있겠네요. 이러한 이해관계를 제쳐두고, '이더리움에 무엇이 가장 좋냐'를 기준으로 판단했을 때에도 사람들의 의견이 갈리는 상황으로 보입니다. 클라이언트와 개발자 툴링 쪽의 복잡도가 가장 큰 블로커인 만큼, 그들의 의견이 제일 중요해 보이네요.