2~3KB 서명을 메모리풀서 검증·집계, 이더리움 EIP-8288 초안
이더리움 개발자들이 서명과 암호 증명을 메모리풀에서 검증·집계하고 블록에는 재귀 STARK를 담는 EIP-8288 초안을 냈다. 제안서가 든 해시 기반 서명은 약 2~3KB이고 직접 검증에 15만~20만 가스가 든다.
토포AI로 이 기사 더 깊이 읽기
이더리움(ETH) 개발자들이 서명과 암호 증명을 메모리풀에서 검증·집계하고, 블록에는 이를 포괄하는 재귀 STARK를 담는 방안을 제안했다. EIP-8288 초안은 양자내성 서명처럼 크고 검증 비용이 높은 암호 자료를 블록에 반복해서 싣는 부담을 줄이려는 구상이다.
EIP-8288(In-mempool signature and proof aggregation)은 비탈릭 부테린(Vitalik Buterin)과 토머스 코라트거가 6월 3일 작성했다. 현재 상태는 '초안(Draft)'이다. 제안서는 검토 중인 해시 기반 서명이 약 2~3KB이며, 직접 검증에 15만~20만 가스가 들 수 있다고 설명한다. 이는 제안서가 든 예시 추정치로, 모든 서명 방식이나 실제 구현의 확정 수치는 아니다.
메모리풀은 트랜잭션이 블록에 담기기 전에 대기하는 공간이다. 설계에서는 트랜잭션이 서명·증명 원자료 대신 검증 의존성을 선언한다. 노드는 트랜잭션을 전달하기 전에 의존성을 검증하고, 메모리풀 노드와 블록 빌더는 여러 증명을 묶는다. 블록에는 포함된 트랜잭션의 의존성 전체가 유효하다는 것을 보이는 재귀 STARK 하나를 담는다.
STARK는 계산이 올바르게 수행됐음을 보이는 암호 증명이고, 재귀 방식은 다른 증명의 유효성까지 하나의 증명 안에 묶는다. 따라서 자료가 네트워크에서 사라지는 것은 아니며, 검증과 집계가 이뤄지는 위치가 달라진다.
이 방식은 새 서명 체계가 나올 때마다 별도 검증 기능을 추가하는 부담을 줄이려는 목적도 있다. 초안은 EIP-8141 프레임 트랜잭션을 토대로 서명과 STARK 증명을 같은 경로에서 처리하도록 설계했다. 프레임 트랜잭션은 계정이 자체 검증 로직과 서명 방식을 선택하도록 설계된 구조다. 초안은 FOCIL 포함 목록에도 재귀 STARK를 붙이는 호환 방안을 함께 제시했다.
배경에는 비용 문제가 있다. 양자내성 서명과 프라이버시 증명은 기존 방식보다 데이터 크기와 검증 비용이 커질 수 있다. 제안서는 새 암호 방식마다 별도 기능을 추가하는 대신 서명·증명을 STARK로 감싸 메모리풀 단계에서 함께 집계하는 공통 경로를 택했다.
부담이 사라지는 것은 아니다. 메모리풀에서 증명 검증·집계 작업이 늘어날 수 있고, 초안도 메모리풀의 서비스 거부 공격 노출이 증가할 가능성을 적었다. 초안은 한 트랜잭션에 허용되는 서명·STARK 의존성 수에도 제한을 두는 방안을 제시했다. STARK 증명 자체도 128KB를 넘거나, 빠른 생성에 맞춘 경우 약 512KB까지 커질 수 있다고 설명한다. 모두 제안서의 설계상 수치다.
증명 대상 프로그램의 명령어 집합을 무엇으로 정할지도 논의 중이다. 10월 8일 이더리움 리서치(Ethereum Research)에 올라온 개발자 글은 EVM, RISC-V, 이더리움 전용 명령어 집합을 비교했다. 글은 RISC-V가 증명 도구와 효율 면에서 선택지가 될 수 있지만, 명령어 규칙과 버전을 장기간 유지해야 한다고 짚었다. 해당 글은 선택지를 비교하는 단계의 기술 논의다.
본지가 앞서 전한 부테린의 EIP-8288 구상은 여러 서명 검증을 STARK 증명으로 집계하는 방향을 다뤘다. 이번 개발자 논의는 증명 기준으로 삼을 명령어 집합과 장기 호환성 문제를 구체적인 쟁점으로 제시했다. 부테린은 9월 27일 글에서 재귀 STARK와 서명 집계를 이더리움의 장기 구상에 포함했지만, 확정된 업그레이드 일정이나 기능 목록은 아니었다.
EIP-8288은 초안 단계이며, 채택 여부와 포크 일정은 확인되지 않았다.

이준한 기자 




댓글 0
불러오는 중…