네이티브 계정 추상화 논의 - 프로토콜이 어디까지 책임져야 하는가

[네이티브 계정 추상화 논의 - 프로토콜이 어디까지 책임져야 하는가] 오늘 이더리움 재단 주최로 ‘Frame Transaction Breakout’ 콜이 잡혀, 네이티브 계정 추상화와 관련된 격렬한 논의가 펼쳐졌습니다. 현재 이더리움의 다다음 업그레이드인 헤고타는, 테마가 네이티브 계정 추상화입니다. 스마트 계정을 프로토콜의 일등 시민으로 만들어, 생태계 전체의 UX와 양자 저항성 등을 높이려는 것이 목표이죠. 그런데 이 목표를 달성하는 방법을 두고 현재 두 가지 방향이 경쟁하고 있습니다. EIP-8141: 프로토콜은 최대한 범용적인 틀을 제공하자 현재 이더리움 메인넷에서 논의가 가장 앞서 있는 제안은 EIP-8141, ‘프레임 트랜잭션’입니다. 프레임은 하나의 거래를 여러 개의 ‘프레임’으로 쪼개고, 이를 개발자들이 알아서 조합하도록 하여, 인증, 실행, 수수료 지불 같은 여러 과정을 유연하게 구성할 수 있는 틀을 프로토콜이 제공하자는 것입니다. 어떤 방식으로 서명할지, 누가 계정을 제어할지, 수수료를 누가 낼지 같은 구체적인 계정 설계는 그 위에서 자유롭게 만들 수 있습니다. 해당 접근의 가장 큰 장점은 유연성입니다. 앞으로 새로운 서명 기술이 나오거나, 새로운 형태의 스마트 계정이 등장하거나, 지금은 예상하지 못한 사용 사례가 생겨도 프로토콜 자체를 크게 바꾸지 않고 대응할 수 있습니다. 이더리움은 낮은 수준의 도구를 제공하고, 실제 계정 구조는 지갑과 애플리케이션이 발전시켜 나가는 그림이죠. 현재 여러 실행 클라이언트 팀이 EIP-8141 구현과 검증에 참여하고 있고, 프라이버시 거래나 새로운 서명 방식 등 다양한 기능도 그 위에서 실험되고 있습니다. EIP-8130: 계정의 공통 기반을 프로토콜이 맡자 최근에는 베이스를 중심으로 EIP-8130이라는 또 다른 제안이 빠르게 부상했습니다. EIP-8130이 집중하는 부분은 ‘계정을 누가 어떤 방식으로 제어하는가’입니다. 지금의 일반 계정은 하나의 개인키와 하나의 주소가 강하게 연결되어 있습니다. 스마트 계정이 되면 상황이 복잡해집니다. 여러 개의 키를 사용할 수도 있고, 기기별로 권한을 다르게 줄 수도 있고, 일정 기간만 사용할 수 있는 키를 만들 수도 있습니다. EIP-8130은 이런 권한 관계를 프로토콜이 이해할 수 있는 공통된 형태로 관리하자는 접근입니다. EIP-8130은 계정과 인증 방식을 분리하여, 계정은 그대로 두고, 이 계정을 누가 어떤 권한으로 사용할 수 있는지를 프로토콜 내에 정의된 별도의 공통 구조에서 관리합니다. 이렇게 되면 특정 지갑에서 만든 스마트 계정을 다른 체인에서도 비슷한 방식으로 사용할 수 있고, 지갑마다 키 관리와 권한 구조를 처음부터 다시 만들 필요도 줄어듭니다. 베이스는 이 구조를 실제 네트워크에 도입할 계획이고, 옵티미즘 및 아비트럼 등 다른 레이어2들도 관심을 보이고 있습니다. 결국 논점은 ‘프로토콜이 어디까지 해야 하는가’ 오늘 논의에서 가장 크게 부딪힌 지점은, 프로토콜이 어디까지 정의해야 하는지 였습니다. EIP-8141을 지지하는, 대부분의 L1 클라이언트 팀들 및 리서처들은 이더리움 프로토콜이 특정한 계정 구조를 너무 많이 규정하는 것을 피해야 한다고 주장합니다. 한번 프로토콜에 들어간 구조는 바꾸기가 매우 어려우며, 새로운 서명 방식이나 새로운 계정 설계가 등장할 때마다 하드포크와 거버넌스 논의가 필요해질 가능성도 있기 때문입니다. 특히 양자 저항 서명처럼 기술 변화가 빠른 분야에서는 이 문제가 더 크게 느껴질 수 있죠. 즉, 어떤 기술이 최종 승자가 될지 아직 알 수 없는 상황에서, 최대한 다양한 방식을 수용할 수 있는 기반을 만들어두자는 주장입니다. EIP-8130을 긍정적으로 보는 쪽에서는 지나친 자유도가 파편화로 이어질 수 있다고 봅니다. 현재 스마트 계정 지갑들은 키 교체, 권한 관리, 거래 묶음 처리, 수수료 대납처럼 비슷한 기능을 각자 반복해서 구현하고 있습니다. 사용자 입장에서는 한 지갑이나 한 체인에서 잘 작동하던 계정이 다른 환경으로 이동하면 다시 달라지는 문제가 생길 수 있죠. 따라서 계정의 가장 기본적인 권한 구조 정도는 공통으로 맞춰두는 것이 생태계 전체의 사용자 경험에 도움이 된다는 이야기입니다. 메인넷과 레이어2가 서로 다른 길을 갈 수도 있다 이 문제가 더 중요해진 이유는 EIP-8130이 실제 레이어2에서 채택되기 시작했기 때문입니다. 베이스는 이미 테스트넷에서 EIP-8130을 구현 완료하였으며, 올해 9월에 메인넷에 도입할 계획입니다. 옵티미즘도 이를 따라 구현하기로 약속한 상황이며, 아비트럼도 구현에 열려있는 상황이죠. 한편 이더리움 메인넷에서는 EIP-8141 개발이 이미 상당히 진행된 상태입니다. 여러 클라이언트 팀이 구현에 참여했고, 테스트넷을 향한 준비도 이어지고 있습니다. 이 상태가 계속되면 앞으로 이더리움 메인넷과 주요 레이어2들이 서로 다른 계정 추상화 구조를 사용할 가능성이 생기며, 계정 구조 측면에서 L1과 L2가 서로 다른 방식으로 발전하기 시작하면 지갑과 애플리케이션이 여러 체인을 지원할 때 부담이 커질 수 있습니다. 그래서 오늘 회의에서는 어느 한쪽을 빨리 선택하는 것보다, 가능한 공통 기반을 찾는 것이 중요하다는 의견도 강하게 나왔습니다. 절충점으로 떠오른 ‘키 저장소’ 표준 논의 후반부에서 가장 구체적으로 나온 아이디어는 EIP-8130의 ‘키 저장소’ 구조를 별도로 떼어내 표준화하는 것이었습니다. 계정을 제어할 수 있는 키와 권한 정보를 공통된 방식으로 관리하는 부분입니다. 이 구조를 독립적인 표준으로 만들어 L1과 L2가 동시에 도입하도록 한다면, 메인넷은 프레임 트랜잭션을 사용하고, 레이어2는 다른 거래 구조를 사용하더라도 계정을 제어하는 핵심 정보는 공유할 수 있습니다. 몇몇 참석자들은 이를 별도의 EIP로 만들어 검토하는 방안을 다음 단계로 제안하기도 했죠. EIP-8141의 유연성을 유지하면서, 서로 다른 EVM 체인 간 계정에 일관성을 부여해 생태계의 파편화를 막을 수 있는 지점이라고 볼 수 있을 것 같습니다. 현재까지의 방향 회의에서 기존 계획이 뒤집히거나, 참여자들의 의견이 크게 바뀐 부분은 없습니다. 이더리움 메인넷에서는 EIP-8141을 중심으로 한 작업이 계속 진행되고 있으며, 베이스를 비롯한 일부 레이어2에서는 EIP-8130 도입이 추진되고 있죠. 다만 앞으로의 논의는 두 제안에서 어떤 요소를 공통으로 가져갈 수 있는지에 더 집중될 가능성이 커 보입니다. 특히 키와 인증 정보를 관리하는 방식이 중요한 논점이 될 것으로 보입니다. 이더리움은 계정까지 표준화해야 할까 결국 이번 논쟁이 던지는 질문은 “이더리움 프로토콜은 어디까지 책임져야 할지”입니다. 스마트 계정을 만들 수 있는 충분한 도구를 제공하고, 그 위의 경쟁과 혁신을 시장에 맡길 수도 있습니다. 계정의 권한과 인증처럼 모든 사용자가 반복해서 필요로 하는 부분은 공통 기반으로 만들어, 어느 지갑과 어느 체인에서도 비슷한 경험을 제공할 수도 있죠. 결국 범용성와 통일성 간 트레이드오프를 잘 조절해야 할 것으로 보이며, 이에 따라 범 이더리움 생태계의 UX가 크게 달라지지 않을까 싶네요.