EIP-7645 ORIGIN을 SENDER로 별칭 처리 (Alias ORIGIN to SENDER)
Hegota 포함 제외 (DFI) · EVM·실행 · 원문 상태 Stagnant · 2024-03-03 작성
EVM의 ORIGIN 명령어가 거래를 처음 시작한 계정 대신 바로 앞 호출자의 주소, 즉 SENDER와 같은 값을 돌려주도록 바꾸는 제안입니다.
왜 필요한가
ORIGIN 명령어는 거래를 처음 시작한 계정의 주소를 돌려주고 SENDER(CALLER) 명령어는 바로 앞 호출자의 주소를 돌려줍니다. 이 둘을 구분하는 방식은 피싱 공격 같은 보안 문제를 일으킬 수 있어 2016년 중반부터 사용이 권장되지 않았습니다. 예를 들어 ERC-4337의 번들러(여러 사용자 작업을 묶어 제출하는 주체)가 ORIGIN으로 권한을 확인하는 컨트랙트에 토큰이나 권한이 있으면, 번들러가 묶어 처리하는 어떤 거래든 그 권한을 가로챌 수 있습니다. 하위 호출에서도 ORIGIN이 계속 번들러 주소로 남기 때문입니다. 또 EIP-7377, EIP-3074 같은 계정 추상화 시도는 모두 ORIGIN을 바꾸거나 우회하는 문제를 먼저 풀어야 합니다. 그래서 원문은 ORIGIN이 이더리움 계정 모델을 더 유연하게 바꾸는 데 걸림돌이 된다고 봅니다.
무엇이 바뀌나
지금
- ORIGIN(0x32)은 거래를 처음 시작한 계정의 주소를 돌려줍니다
- 여러 단계를 거친 호출에서도 ORIGIN은 최초 발신자 주소로 고정됩니다
- 최초 발신자와 직접 호출자를 구분하는 로직이 피싱 등 권한 탈취에 악용될 수 있습니다
EIP-7645 이후
- ORIGIN이 모든 실행 맥락에서 SENDER(0x33)와 같은 값을 돌려줍니다
- 호출 단계마다 ORIGIN이 바로 앞 호출자의 주소로 바뀝니다
- 두 값을 구분하던 데서 생기던 보안 허점이 사라지고 계정 추상화의 공통 걸림돌이 제거됩니다
누구에게 영향이 있나
- 컨트랙트 개발자: ORIGIN으로 거래 시작 주소를 얻던 컨트랙트는 새 정의에서도 올바르게 동작하는지 점검해야 하고 문제가 생기는 코드는 우회하거나 피해야 합니다.
- 클라이언트 팀: ORIGIN이 호출될 때 SENDER를 실행한 것처럼 현재 호출의 발신자 주소를 스택에 올리도록 모든 클라이언트가 EVM을 바꿔야 합니다.
- 계정 추상화 생태계: 모든 계정 추상화 제안이 부딪히는 ORIGIN 처리 문제가 사라져 설계가 단순해집니다.
- 사용자: ORIGIN을 잘못 쓰는 레거시 코드가 이 변경으로 영향을 받을 수 있어 그런 코드를 피하도록 안내가 필요할 수도 있습니다.
심층 설명
정의 변경: 0x32가 0x33과 같은 값을 반환
현재 ORIGIN 옵코드는 거래를 처음 시작한 주소를 반환합니다. 이 EIP에서 ORIGIN 옵코드(0x32)는 모든 실행 맥락에서 SENDER(CALLER로도 불림) 옵코드(0x33)가 반환하는 값과 같은 값을 반환해야 합니다(MUST). 즉 최초 발신자 추적 기능 자체를 제거하는 것이 아니라, ORIGIN을 SENDER의 별칭으로 만들어 두 옵코드가 항상 같은 값을 내놓게 합니다. 홉이 없는 단순 거래에서는 지금도 두 값이 같으므로, 실제로 달라지는 것은 컨트랙트가 다른 컨트랙트를 다시 호출하는 다중 홉 상황입니다.
EVM 구현과 거래 검증
모든 이더리움 클라이언트는 ORIGIN 옵코드가 호출될 때, SENDER 옵코드가 실행된 것처럼 현재 호출의 발신자 주소를 스택에 올리도록 EVM을 바꿔야 합니다(MUST). 거래 검증은 지금과 똑같이 이뤄지며 위에서 정한 옵코드 동작 말고는 거래 구조나 처리 로직에 바뀌는 것이 없습니다. 변경 범위를 EVM 내부의 옵코드 하나로 좁혀 둔 설계입니다. 원문은 구현자들이 이 명세에 피드백을 주고 구현이나 테스트 과정에서 발견한 문제를 보고해 달라고 요청합니다.
세 가지 근거: 계정 추상화, 보안, 기술 부채
원문이 드는 근거는 세 가지입니다. 첫째, 계정 추상화 촉진입니다. 모든 계정 추상화 시도가 공통으로 부딪히는 장벽을 깔끔하게 없애 더 유연한 계정 모델을 가능하게 합니다. 둘째, 보안 강화입니다. 최초 발신자와 직접 호출자를 구분하는 데서 생기는 취약점을 제거합니다. 셋째, 기술 부채 정리입니다. 오래전부터 사용이 권장되지 않던 기능을 없애 EVM의 거래·실행 모델을 단순하게 만들고 앞으로의 변경을 더 쉽고 안전하게 만듭니다.
하위 호환성: 완전하지 않음
이 변경은 완전한 하위 호환이 아닙니다. ORIGIN과 SENDER의 구분에 로직이나 보안을 의존하는 컨트랙트는 영향을 받습니다. 그래서 명세는 ORIGIN으로 거래 시작 주소를 얻는 컨트랙트를 점검해 새 정의에서도 올바르게 동작하는지 확인하고 깨지는 경우 우회하거나 피하라고 요구합니다(MUST). 원문은 ORIGIN 사용이 오랫동안 권장되지 않았고 영향이 작으며 어떤 계정 추상화 해법이든 결국 ORIGIN을 처리해야 한다는 점을 들어 이 비호환을 필요한 진전으로 봅니다.
테스트 케이스: 네 가지 호출 방식의 직접·다중 홉 검증
CALL, STATICCALL, DELEGATECALL, CALLCODE 각각에 대해 두 가지를 확인합니다. 직접 호출(Direct)에서는 대상 컨트랙트에서 ORIGIN과 SENDER가 같은 값을 내는지 확인합니다. 홉이 없는 단순 거래에서는 지금도 이미 같습니다. 다중 홉(Multi-hop)에서는 여러 단계를 거치는 거래의 각 호출 프레임마다 ORIGIN과 SENDER가 같은 값을 내는지 확인합니다.
보안 고려: ORIGIN 전면 금지 가능성
별칭 처리로 ORIGIN 옵코드와 관련된 특정 보안 취약점은 해소됩니다. 원문은 이 EIP 범위 밖의 이야기로, 오해와 오용을 더 줄이려면 ORIGIN 사용 자체를 금지하는 것이 현명할 수 있다고 덧붙입니다. 방법으로는 EVM 바깥의 도구 변경, 또는 EVM 안에서 ORIGIN을 쓰는 컨트랙트 배포를 되돌리는(revert) 방식을 듭니다. 별칭 처리로 나빠지는 기존 오용 사례는 아직 명확한 예가 확인되지 않았지만 그런 레거시 코드를 피하도록 사용자를 교육할 필요가 있을 수 있다고 적습니다.
현재 상태: Stagnant, 포크에서도 제외
원문 상태는 Stagnant입니다. 오랫동안 진전이 없어 논의가 멈춘 상태이며 다시 활성화되지 않으면 이대로 채택되지 않을 수도 있습니다. 코어 개발자 콜에서도 09.10 ACDE #245에서 Hegota 포크 대상에서 EIP-2488, EIP-8219, EIP-8182와 함께 EIP-7645를 제외했습니다. 네 건 모두 전 클라이언트 만장일치 저평가(0.0~0.8)였습니다.