EIP-8163은 이더리움 L1 EVM에서 0xae 옵코드를 영구히 예약하자는 제안이다. L1에서는 기존의 INVALID (0xfe)와 동일하게 동작하여 프로토콜 변경이 전혀 없지만, L1 외부의 EVM 체인들은 이 옵코드를 확장 명령어의 접두사로 자유롭게 활용할 수 있게 된다. 이더리움이 "이 번호는 절대 쓰지 않겠다"고 공식 약속함으로써, 다른 EVM 체인들이 옵코드 충돌 걱정 없이 독자적인 EVM 확장을 시도할 수 있는 네임스페이스를 보장하는 것이다.
이 제안의 의미는 EVM을 채택한 alt-L1들이 겪는 종속성 딜레마의 완화에 있다. 독자 VM을 만들면 생태계를 처음부터 구축해야 하는 비용이 크고, EVM을 그대로 따르면 이더리움 L1의 프로토콜 변경에 수동적으로 끌려갈 수밖에 없다. 이에 대해서는 최근 EIP-8141(Frame Transaction)에 대한 논쟁이 잘 보여준다. EIP-8141은 트랜잭션의 유효성이 검증 프레임의 EVM 실행 결과에 따라 동적으로 결정되는 구조인데, 이는 Tempo처럼 자체 트랜잭션 설계를 가진 체인에게는 쓰이지 않을 dead code를 강제로 탑재하는 것과 같고, 합의와 실행을 분리하여 트랜잭션 순서에 대해 먼저 합의한 뒤 실행을 별도 파이프라인에서 처리하는 모나드에게는 "합의 전 실행 필수"를 강제하여 아키텍처의 근간을 흔드는 문제가 된다. EVM 동등성을 유지하려면 받아들여야 하고, 거부하면 호환성을 포기해야 하는 딜레마다.
모나드 측에서 EIP-8163을 제안했다는 점은 이러한 맥락에서 자연스럽게 읽힌다. L1의 프로토콜 변경에 일방적으로 종속되는 것이 아니라, 합의된 확장 공간 안에서 각 체인이 자기 아키텍처에 맞는 실험을 할 수 있는 구조를 확보하려는 시도인 것이다.
이 제안 자체는 이더리움 L1에 아무런 실질적 변경을 가하지 않고, 성공적인 확장 기능은 별도 EIP를 통해 L1으로 역이식할 수 있다는 점에서 리스크가 낮다. 이더리움 프로토콜의 진화 속도는 결국 클라이언트 개발자와 툴링 빌더들이 감당할 수 있는 복잡도의 한계에 달려 있으며, EIP-8163의 접근은 그 한계를 우회하는 현실적 해법이 될 수 있다고 본다.
Monad
