이더리움의 검열 불가능한 프라이버시를 위한 두 개의 받침대, EIP-8250과 EIP-8272

[이더리움의 검열 불가능한 프라이버시를 위한 두 개의 받침대, EIP-8250과 EIP-8272] 지난 4월 16일과 5월 15일, 네이티브 계정 추상화 제안인 EIP-8141의 후속 제안 두 개인, EIP-8250(Keyed Nonces)과 EIP-8272(Recent Roots)가 잇따라 공개됐습니다. 둘 다 이더리움 위의 프라이버시 프로토콜이 EIP-8141 위에서 실제로 굴러가도록 지원하는 EIP입니다. 만약 헤고타에서 위 EIP들이 모두 적용된다면, 이더리움 위 중개자 없는 프라이버시 프로토콜을 구현할 수 있을 것으로 보입니다. [EIP-8141의 목적 중 하나: 프라이버시] EIP-8141은 헤고타 포크를 목표로 하는 네이티브 계정 추상화 제안입니다. 한 트랜잭션을 여러 '프레임'으로 쪼개서, 각 프레임이 검증/결제/실행을 따로 맡게 하는 구조죠. 이 제안은 언뜻 보면 프라이버시와 별로 상관이 없지만, 사실은 그렇지 않습니다. 이 표준을 잘 활용하면, 프라이버시 프로토콜이 더 이상 릴레이어(broadcaster)에 의존하지 않아도 되죠. 지금 레일건이나 토네이도 캐시 같은 프로토콜들은, 트랜잭션을 보내기 위해 사용자가 릴레이어에게 요청을 보내야만 합니다. 만약 사용자가 직접 트랜잭션을 보낸다면 사용자의 신원이 발신자 주소에 묶이기 때문에, 제3자 릴레이어가 대신 보내주는 것이죠. EIP-8141을 활용하면, 이 중개자를 아예 없앨 수 있습니다. 바로 프라이버시 프로토콜 컨트랙트 자체를 유저들의 ‘공용 계정’으로 사용하는 것입니다. EIP-8141이 도입되면, 컨트랙트가 트랜잭션 발신자가 될 수 있기 때문에, 공유 컨트랙트 하나를 발신자로 삼고, 그 안에서 사용자별로 ZK 증명으로 본인이 가진 돈을 인증하고 프라이빗 출금이나 자금 전송을 수행하는 것이죠. 비탈릭이 트위터에서 EIP-8141을 "프라이버시 프로토콜의 1급 시민화"라고 부르던 게 이러한 의미입니다. 근데 이 그림이 실제로 작동하려면, 8141만으론 두 가지 구조적 문제가 남습니다. [문제 1: 공유 발신자의 직렬화 병목] "한 컨트랙트가 N명의 사용자를 대표한다"는 모델에는 함정이 있습니다. 발신자에게는 단 하나의 선형 논스만 있어서, 사용자 A의 트랜잭션이 어떤 이유로든 지연되면 B, C, D가 그 뒤에 줄지어 기다려야 한다는 거죠. 서로 완전히 무관한 출금인데도 말입니다. 프라이버시는 본질적으로 사용자들이 서로의 활동에 영향받지 않는다는 전제 위에 서 있는데, 이 전제가 깨지는 것입니다. 서로 동시에 트랜잭션을 보내면, 수수료를 더 많이 낸 사용자의 트랜잭션만 블록에 포함되고, 나머지는 모두 실패하게 됩니다. [문제 2: 검증 단계에서 외부 상태를 읽지 못함] EIP-8141의 검증 프레임(VERIFY)은 STATICCALL처럼 동작합니다. 상태 변경이 안 되는 건 당연하고, 공개 멤풀 안전성을 위해 외부 컨트랙트 상태를 자유롭게 읽는 것도 한됩니다. 이 제한이 없으면, 누군가 스토리지 하나를 바꾸는 것만으로 멤풀에 떠 있는 수많은 트랜잭션을 한 번에 무효화시키는 DoS 공격을 수행할 수 있기 때문입니다. 문제는 프라이버시 프로토콜이 ZK 증명을 검증하려면, 해당 프로토콜이 사용하는 머클 트리의 최근 루트가 필요하다는 점입니다. 즉, 현재 EIP-8141 표준만으로는 프라이버시 프로토콜을 구현할 수 없습니다. [해결: EIP-8250과 EIP-8272] 두 제안은 각각의 문제를 해결합니다. • EIP-8250 (Keyed Nonces) 기존의 단일한 논스를 (key, seq) 쌍으로 쪼갭니다. 키가 0이면 기존 계정 논스 그대로(하위 호환), 0이 아니면 키마다 독립된 논스를 갖죠. 서로 다른 키의 트랜잭션은 독립적이라, 한 사용자가 다른 사용자를 막지 못합니다. 흔히 '2D 논스'라고 불리며, ERC-4337에서 한 계정이 여러 시퀀스를 병렬로 굴리는 용도로 이미 쓰여 온 개념입니다. 프라이버시 프로토콜에서는 이걸 무효화자(nullifier)에 접목해 사용합니다. 토네이도 캐시 같은 프로토콜에서 출금할 때, 내가 어떤 입금(commitment)을 쓴 것인지 온체인에 그대로 드러내면 입금-출금이 연결돼 프라이버시가 깨집니다. 그래서 프라이버시 프로토콜은 입금마다 고유한 무효화자라는 일회용 라벨을 도입합니다. 온체인에는 무효화자만 공개하고, ZK 증명 안에서 "이 무효화자가 트리 안의 어떤 입금에 대응한다"는 사실만 증명하는 거죠. 한 번 등장한 무효화자는 다시 못 쓰게 막아서 이중지불도 함께 방지합니다. 이 2D 논스가 도입되면, 프라이버시 프로토콜은 논스의 키 자리에 이 무효화자를 그대로 넣게 됩니다. 각 자금의 무효화자가 고유하니 사용자들은 서로 방해받지 않으며, 프로토콜이 시스템 컨트랙트에 그 키를 영구히 마킹해 주니 무효화자 중복 사용 방지까지 EVM 레벨에서 보장됩니다. 앱 컨트랙트가 자기 스토리지에 무효화자 테이블을 관리하던 일을 프로토콜이 대신 해 주는 셈이죠. • EIP-8272 (Recent Roots) EIP-8141 트랜잭션에 자기가 검증에 참조할 (source id, slot, root) 리스트를 선언할 수 있게 합니다. 이게 도입되면, 프라이버시 프로토콜은 새 루트가 생길 때마다 시스템 컨트랙트에 슬롯 단위로 제출하게 됩니다. 해당 프로토콜을 사용하는 사용자는, 본인이 생성한 ZK 증명의 기반이 되는 루트를 트랜잭션에 직접 명시합니다. 그러면 클라이언트가 프레임 실행 전에 이 루트가 진짜 그 프로토콜이 제출한 것인지 미리 검증해 주고, 검증 프레임은 전용 명령어로 트랜잭션 안의 루트를 꺼내 ZK 증명 검증에 사용하죠. 즉, EIP-8272는 EIP-8141의 검증 프레임 제한에 대한 좁고 명시적인 예외를 뚫는 제안입니다. 외부 상태를 자유롭게 읽는 건 여전히 막혀 있지만, "사전에 검증된 최근 루트"라는 좁은 형태로는 검증 단계에 끌어올 수 있게 되는 거죠. 꼭 프라이버시에만 쓸 필요는 없어서 지갑 권한 루트, 과거 상태 루트 등 다양한 응용에도 활용될 수 있을 것으로 보입니다. [결론] EIP-8141이 "프라이버시 프로토콜을 멤풀로 직접 보낸다"는 큰 그림을 그렸다면, EIP-8250과 EIP-8272는 그 그림이 현실에서 작동하기 위한 받침대들입니다. 한쪽은 사용자 간 동시성을 풀어주고, 다른 쪽은 검증에 필요한 값을 안전하게 제공합니다. 두 제안이 함께 자리잡아야 비로소 레일건, 프라이버시 풀즈 같은 프로토콜이 릴레이어 없이 L1에서 굴러갈 수 있는 그림이 완성됩니다. 각 제안이 꼭 프라이버시 프로토콜에만 적용 가능한 것은 아니라는 점도 주목할 만한 듯 합니다. EIP-8250은 기존 AA 지갑에서도 자주 사용되었던 2D 논스를 도입하고, EIP-8272를 활용하면 세션 키와 같은 것들을 쉽게 구현할 수 있죠. 즉, 위 제안들은 프라이버시 프로토콜 사용 사례가 가장 큰 목표기는 하나, 다른 사용 사례도 포괄할 수 있는 범용적인 제안이라는 것입니다.