서명한 뒤의 마지막 검사: 이더리움 거래 결과를 되돌릴 수 있을까

명령서와 영수증 사이

어떤 자산을 내주고 다른 자산을 최소한 정해진 수량만큼 받기로 했다고 가정해 보자. 화면은 실행할 동작을 보여 주지만, 내가 원하는 것은 그 뒤 지갑에 남을 잔액이다. 두 약속은 연결되어 있어도 같은 말은 아니다. 서명은 거래 데이터를 승인한다. 머릿속 기대까지 모두 실행 가능한 조건으로 바꾸어 주지는 않는다. 실제 실패 사례가 아니라 차이를 설명하기 위한 가정이다.^[1][2]

이더리움 재단의 10월 5일 해설은 이 간격을 다룬다. 읽기 쉬운 서명 화면은 요청된 동작을 풀어 주고, 시뮬레이션은 특정 블록체인 상태에서 예상 결과를 계산한다. 실제 실행 시점에는 상태나 컨트랙트의 동작이 달라질 수 있다. EIP-7906이 던지는 질문은 한 걸음 더 나아간다. 거래에 마지막 결과 검사를 붙이고, 그 검사에 실패하면 실행 효과를 거절할 수 있을까?^[2]

익숙한 조건 검사에 더 넓은 시야를

애플리케이션 안에는 이미 결과 조건이 있다. 유니스왑 v3의 교환 인터페이스는 amountOutMinimum으로 최소 수령량을 정한다. 개발자 문서는 학습용 예제처럼 이 값을 0으로 두는 것이 실제 운영에서는 위험하다고 경고한다. 검사 장치가 있다는 사실만으로 충분하지 않다. 검사할 조건이 의미 있는 경계를 정해야 한다.^[7]

새 제안은 거래 중 무엇이 바뀌었는지를 검사 컨트랙트가 더 일반적인 방식으로 볼 수 있게 하려는 것이다. 호출하는 앱마다 내장된 검사에만 의존하지 않고, 지갑이 별도 조건 검사를 붙일 수 있다. EIP-7906은 또 다른 초안인 EIP-8141에 의존한다. EIP-8141은 거래를 검증, 가스비 지불 승인, 실행 등 역할이 다른 프레임으로 나눈다. 여기에 마지막 검사 모드를 추가하는 구조다.^[1][3]

일을 마친 뒤, 같은 거래 안에서 확인한다

현재 명세에서 ASSERT 프레임은 거래 맨 뒤에 연속해서 놓인다. 읽기 전용이므로 검사기가 상태를 바꾸고 그 결과를 스스로 승인할 수 없다. TXTRACE는 거래가 만든 변화를 열거하고, TXDIFF는 특정 계정이나 저장 공간의 값을 조회하며, EVENTDATACOPY는 발생한 이벤트 데이터를 읽게 한다. 일반 지갑에 이미 있는 버튼이 아니라 제안된 EVM 명령어다.^[1]

상태 차이는 모든 동작을 촬영한 동영상보다 전후 비교표에 가깝다. 같은 저장 슬롯을 여러 번 바꾸어도 순변화로 합쳐지며, 시작 값으로 돌아온 항목은 그 목록에 순변화로 나타나지 않는다. 기본 자산인 ETH 잔액, 컨트랙트 저장 값, 배포된 코드는 서로 다른 정보다. 토큰의 경제적 의미를 해석하려면 알맞은 로직도 필요하다. 저장 값만 읽는다고 모든 토큰과 권한이 사람에게 익숙한 목록으로 저절로 정리되지는 않는다.^[1]

앞의 가상 교환에서는 지정한 수령인이 약속한 최소 수량을 받았는지 검사할 수 있다. 하지만 그것만 검사하면 다른 곳의 무관한 변화까지 금지되지는 않는다. 어떤 자산, 수령인, 권한이 중요한지도 조건에 담아야 한다. 프로토콜은 검사를 실행할 수 있어도, 거래하라는 폭넓은 허가만으로 사용자의 모든 의도를 알아낼 수는 없다.^[1]

되돌리기에는 경계와 비용이 있다

ASSERT 검사가 실패하면 현재 설계는 가스비 지불을 승인한 프레임 직후까지 실행 본문을 되돌린다. 거래 자체는 블록에 포함될 수 있는 유효한 거래로 남고, 지불자는 이미 사용한 가스의 비용을 낸다. 따라서 검사 실패가 거래 전체를 지우거나 실패한 시도를 무료로 만든다고 설명하면 틀린다.^[1][5]

앞선 검증 구간인 validation prefix는 유지된다. 이 구간에는 지불 승인뿐 아니라 계정 배포도 들어갈 수 있다. 지갑은 보호하려는 외부 앱의 동작을 그 경계 뒤에 배치해야 한다. 앞선 검증 구간에 넣은 동작까지 마지막 검사가 되돌려 주지는 않는다. 10월 15일 수정은 이 구분을 명확히 했다. 처리 비용과 신뢰하는 초기 설정은 기록에 남기면서 실행 결과를 거절하는 구조이지, 만능 취소 버튼이 아니다.^[1][3][5]

받아들일 조건은 누가 정하는가

잘못되거나 악의적인 화면이 지나치게 느슨한 조건을 제시하면 원하지 않은 결과도 검사를 통과할 수 있다. 그래서 명세는 조건의 출처, 입력 값, 검사 코드 자체를 설계의 일부로 다룬다. 같은 거래가 바꿀 수 있는 값을 기준으로 검사하면, 막으려던 동작을 오히려 승인할 수도 있다. 조건은 사용자의 의도를 독립적으로 표현할 만큼 신뢰할 수 있어야 한다.^[1]

모든 거래에 특정 검사를 강제로 붙이는 제안도 아니다. 지갑의 검증 로직은 유용한 검사가 있겠거니 가정하지 말고, 올바른 검사 프레임과 대상, 데이터를 요구해야 한다. 믿을 수 있는 검사기, 적절한 가스 예산, 신뢰할 수 있는 앞선 검증 로직이 여전히 필요하다. 이 장치는 현재 거래의 온체인 효과를 다룬다. 이후 시장 가격의 변화나 다른 체인에서의 이행까지 보장하지 않는다.^[1]

출시된 보장이 아니라 다듬는 중인 명세

10월 5일 블로그는 이 모드를 POST_TX라고 불렀다. 15일 되돌림 경계를 설명하는 수정에 이어, 16일 병합된 변경은 이름을 ASSERT로 바꾸었다. 17일 확인 기준 EIP-7906과 기반이 되는 EIP-8141은 모두 Draft다. Forkcast에는 EIP-7906이 Hegota 포함 검토 단계로 기록되어 있다. 이는 활성화 발표가 아니다. 명세의 성숙도를 나타내는 상태와 업그레이드 편입 일정도 서로 다른 기준이다.^{[1][2][3][4][5][6]}

이 제안의 의미는 지갑이 사용자의 약속을 표현하는 위치를 넓힌다는 데 있다. 서명할 명령에 더해, 실행이 만든 결과에도 조건을 걸 수 있게 하려는 것이다. 실제 보호로 이어지는지는 채택 여부와 지갑이 요구하는 정확한 조건에 달려 있다. 지금 읽어야 할 것은 되돌림 경계가 정해진 결과 제한 장치의 설계다. 이미 서명한 어떤 거래든 나중에 회수할 수 있다는 약속은 아니다.^[1][6]