ERC-7674 ERC-20 임시 승인 확장 (Temporary Approval Extension for ERC-20)

Review · 토큰 · 2024-04-02 작성

ERC-20 토큰에 한 트랜잭션 동안만 유효한 임시 승인(temporary approval)을 추가하는 확장입니다. 임시 승인은 트랜잭션이 끝나면 자동으로 지워져 승인이 남지 않습니다.

왜 필요한가

ERC-20 토큰을 다른 주소가 대신 옮기게 하려면 먼저 승인(approve)으로 한도를 걸어 두어야 합니다. 그런데 실제로는 한 번만 쓰고 말 승인이 많습니다. 이런 상호작용이 끝난 뒤에도 예상치 못한 승인이 그대로 남는 일이 흔합니다. 남은 승인은 트랜잭션이 끝나도 사라지지 않으므로, 승인받은 주소는 이후에도 남은 한도만큼 토큰을 가져갈 수 있습니다. 한편 이더리움에는 트랜잭션이 끝나면 내용이 사라지는 임시 저장 명령어 TSTORE가 EIP-1153으로 도입되었고 이를 이용하면 일시적인 한도를 효율적으로 다룰 수 있습니다. 이 표준은 같은 트랜잭션 안에서만 쓸 수 있는 ERC-20 승인을 위한 최소 인터페이스를 정의합니다.

구현해야 하는 것

심층 설명

새 함수 temporaryApprove

준수하는 컨트랙트는 ERC-20에 더해 함수 1개를 반드시 구현해야 합니다. temporaryApprove(spender, value)를 호출하면 spender는 같은 트랜잭션 안에서 msg.sender를 대신해 여러 번 인출할 수 있고 인출 총액은 value를 넘지 못합니다. 이 임시 한도는 기존 ERC-20의 영구(persistent) 승인에 더해지는 별도의 한도입니다. 따라서 spender가 그 트랜잭션 동안 쓸 수 있는 총액은 임시 한도와 영구 한도의 합으로 제한됩니다.

transferFrom의 소비 우선순위

하나의 transferFrom 호출이 임시 한도와 영구 한도를 함께 소비할 수 있어야 하지만(SHOULD), 소비 순서는 임시 한도가 우선입니다(SHOULD). 임시 한도만으로 충분하면 영구 한도를 저장소에서 읽거나 갱신하지 않아야 합니다. 영구 한도 소비는 저장소 접근을 뜻하므로, 임시 한도가 실행 중인 작업에 모자랄 때에만 수행해야 합니다. 이렇게 하면 일회성 승인 흐름에서 비용이 큰 영구 저장소 접근을 피할 수 있습니다.

임시 승인의 수명

임시 승인은 그것을 만든 트랜잭션이 끝날 때까지 유지되어야 합니다(MUST). 다른 temporaryApprove 호출로 덮어쓰이거나 transferFrom으로 소비되는 경우는 예외입니다. 그리고 각 임시 승인은 그 트랜잭션이 끝나는 시점에 반드시 지워져야 합니다(MUST). 원문은 이를 구현하는 방법으로 EIP-1153의 트랜지언트 스토리지를 쓸 수 있다고 안내합니다. 트랜지언트 스토리지는 트랜잭션이 끝나면 내용이 사라지므로 이 수명 요구사항을 자연스럽게 만족합니다.

allowance 반환값과 하위 호환

allowance 함수는 임시 한도와 영구 한도를 더한 값을 돌려줘야 합니다(MUST). 두 값의 합이 넘치면(오버플로) type(uint256).max를 반환해야 합니다. 이 때문에 ERC-20의 기능 가운데 allowance 함수만 하위 호환이 깨집니다. 원문은 기존 인프라에 쉽게 통합되도록 인터페이스 확장을 최소로 했고 그 대가로 allowance의 의미가 바뀌는 것을 받아들였다고 설명합니다. 또 transferFrom 구현에 요구되는 변경은 스펜더에게 토큰 전송 권한을 명시적으로 부여해야 한다는 요구를 만족한다고 덧붙입니다.

트랜지언트 스토리지 슬롯 유도

임시 승인을 담는 저장 공간은 일반 승인의 저장 공간과 달라야 합니다. 준수 컨트랙트는 EIP-1153의 트랜지언트 스토리지를 쓸 수 있습니다. owner와 spender의 조합마다 슬롯이 겹치지 않게 고유하게 골라야 하며 슬롯 인덱스는 임시 승인용 기준 슬롯 인덱스와 owner, spender 주소에서 유도합니다. 원문은 keccak256(spender . keccak256(owner . p)) 방식을 예로 듭니다. 여기서 .은 이어붙이기이고 p는 해당 컨트랙트의 네임스페이스에서 임시 승인을 고유하게 정의하는 문자열의 keccak256 값입니다.

선택 이벤트 TransientApproval

임시 승인을 설정할 때 이벤트를 내야 한다는 요구는 없습니다. 다만 준수 컨트랙트는 TransientApproval(address indexed owner, address indexed spender, uint256 value) 이벤트를 선택적으로 낼 수 있습니다(may). 이 이벤트는 명세 본문이 아니라 참조 구현 절에 안내된 내용이며 필수 사항이 아니므로 구현에 따라 있을 수도 없을 수도 있습니다.

제안 상태

이 제안은 2024년 4월 2일에 만들어졌고 ERC-20과 EIP-1153을 전제로 합니다(requires: 20, 1153). 현재 상태는 Review로, 아직 검토 단계에 있어 최종 확정 전까지 명세가 바뀔 수 있는 제안입니다. 특히 임시 한도를 먼저 소비하는 우선순위처럼 SHOULD로 적힌 부분은 구현마다 다를 수 있으므로, 실제로 구현하거나 통합할 때는 원문의 최신 상태를 확인하는 것이 좋습니다.

쓸 때 주의할 점

ERC 원문 · ← ERCs