프레임 트랜잭션, 계정이 직접 정하는 검증과 수수료
Strawmap Hegotá (2027) · frame transactions
트랜잭션을 여러 프레임(계약 호출)으로 나누고 서명 검증, 수수료 지불, 실행 방식을 계정 코드가 정하게 하는 새 트랜잭션 유형(0x06)입니다. 계정 추상화를 프로토콜 기본 기능으로 넣습니다.
왜 필요한가
지금 이더리움 계정은 타원곡선 서명(ECDSA) 한 가지로만 보낸 사람을 확인합니다. 계정이 개인키 하나에 묶여 있어 키를 바꿀 수 없고 양자 컴퓨터에 안전한 서명 방식으로 옮겨 갈 길도 없습니다. 여러 작업을 한 번에 묶거나 다른 계정이 수수료를 대신 내려면 스마트 계정 코드와 외부 중개자(릴레이어)를 따로 두어야 해서 구조가 복잡해지고 그만큼 위험도 커집니다. 프레임 트랜잭션은 트랜잭션을 최대 64개의 프레임으로 나누고 각 프레임을 계약 호출로 실행합니다. 어떤 서명을 인정할지, 수수료를 누가 낼지, 무엇을 실행할지를 계정 코드가 정합니다. 그 결과 키 교체, 양자 내성 서명으로 옮기는 일, 일괄 호출, 대체 수수료 지불을 프로토콜이 기본으로 지원합니다. 계정이 코드를 가진 주소가 된다는 계정 추상화(account abstraction)의 원래 구상을 실현하는 제안입니다. 코어 개발자 콜은 이 EIP를 헤고타(Hegotá) 포크의 간판 기능(headliner)으로 올렸습니다. 다만 스펙은 아직 다듬는 중이고 데브넷에서 다른 실행 계층 후보들과 함께 검증하는 단계라 세부 설계는 계속 바뀔 수 있습니다.
어떻게 동작하나
- 프로토콜이 서명을 먼저 확인합니다 트랜잭션에 보낸 사람 주소와 서명 목록이 따로 들어갑니다. 지금 쓰는 secp256k1 서명과 P256 서명은 프로토콜이 직접 확인하고 하나라도 틀리면 트랜잭션 전체가 무효입니다. 임의(ARBITRARY) 형식 서명은 계정 코드가 읽어 스스로 확인합니다.
- 검증 프레임이 승인합니다 검증(VERIFY) 프레임은 상태를 바꿀 수 없는 읽기 전용 호출로 돌아가며 이 트랜잭션을 실행해도 되는지와 수수료를 내도 되는지를 계정 코드가 판단해 승인합니다. 여기서 되돌아가거나 멈추면 트랜잭션은 무효입니다.
- 승인된 뒤 실행 프레임이 돕니다 보낸 사람 자격(SENDER)으로 돌아가는 프레임은 승인이 끝난 뒤에만 실행할 수 있습니다. 프레임은 한 트랜잭션에 최대 64개까지 넣을 수 있고 원자적 배치 플래그로 여러 프레임을 한 묶음으로 처리합니다.
관련 EIP
- EIP-8141 프레임 트랜잭션