ERC-6372 컨트랙트 시계 공개 인터페이스 (Contract clock)

Review · 기타 · 2023-01-25 작성

컨트랙트가 내부에서 시간을 재는 기준이 블록 번호인지 타임스탬프인지를 표준 함수 두 개로 외부에 공개하게 하는 인터페이스입니다.

왜 필요한가

이더리움 컨트랙트는 시간을 재는 일이 많습니다. 타임락(timelock) 컨트랙트는 어떤 작업을 실행하기 전에 일정한 지연을 강제합니다. 다오(DAO)는 제안에 찬반을 표시할 수 있는 투표 기간을 두고 투표 토큰은 시점별 스냅샷으로 투표권의 변화를 저장합니다. 이 시간을 재는 방식은 제각각입니다. 어떤 컨트랙트는 타임스탬프(timestamp)를 쓰고 어떤 컨트랙트는 블록 번호를 쓰며 더 특이한 함수를 쓰는 경우도 있습니다. 그런데 외부에서 특정 컨트랙트가 어느 시계를 쓰는지 알아낼 표준 방법이 지금까지 없었습니다. 그래서 다른 컨트랙트나 앱이 연동하려면 위험한 가정을 해야 했고 상호운용성이 크게 제한됐습니다. 이 표준은 컨트랙트가 자신이 쓰는 시계를 스스로 공개하는 공통 인터페이스를 정해 이 문제를 풉니다.

구현해야 하는 것

심층 설명

clock 함수의 요구사항

표준을 따르는 컨트랙트는 clock과 CLOCK_MODE 두 함수를 반드시 구현해야 합니다(MUST). clock()은 컨트랙트가 동작하는 모드 기준의 현재 시점(timepoint)을 uint48로 돌려주는 view 함수입니다. 이 값은 체인에 대해 감소하지 않는(non-decreasing) 함수여야 하며(MUST), block.timestamp나 block.number가 그 예로 제시됩니다. 입력은 없고 출력은 timepoint라는 이름의 uint48 하나입니다.

CLOCK_MODE 문자열 형식

CLOCK_MODE()는 컨트랙트가 쓰는 시계를 기계가 읽을 수 있는 문자열로 돌려줍니다. 이 문자열은 URL 쿼리 문자열(application/x-www-form-urlencoded) 형식이어야 하며(MUST), 자바스크립트에서 new URLSearchParams(CLOCK_MODE)로 해석할 수 있어야 합니다. 블록 번호 모드에서 NUMBER 옵코드(0x43)의 블록 번호를 쓰면 mode=blocknumber&from=default를 돌려줘야 하고(MUST), 다른 블록 번호를 쓰면 mode=blocknumber&from=<CAIP-2-ID>를 돌려줘야 합니다(MUST). 여기서 <CAIP-2-ID>는 eip155:1 같은 CAIP-2 블록체인 ID입니다. 타임스탬프 모드면 mode=timestamp를 돌려줘야 하며(MUST), 그 밖의 모드면 mode 필드에 고유한 식별자를 넣는 것이 권장됩니다(SHOULD).

왜 uint48인가

반환 타입을 uint48로 정한 이유는 현실적인 값을 담기에 충분하기 때문입니다. 타임스탬프 모드에서는 8921556년까지 담을 수 있고 블록 번호 모드에서 초당 10,000블록이 나오는 극단적인 경우에도 2861년까지 충분합니다. uint256보다 작은 타입을 쓰면 시점 값을 관련 값들과 같은 스토리지에 함께 담는 패킹이 가능해 저장과 읽기 비용이 크게 줄어듭니다. 반면 uint32처럼 더 작은 타입은 레이어 2 등 블록체인의 발전에 따라 꽤 빨리 문제가 될 수 있고 uint48보다 큰 타입은 낭비라고 원문은 설명합니다.

기간 저장에는 uint32 권장

시점뿐 아니라 두 시점의 차이인 기간(duration)이나 지연을 저장해야 할 때도 있습니다. 일반적으로는 시점과 같은 uint48로 표현할 것으로 기대되지만 원문은 대부분의 경우 uint32가 좋은 대안이라고 봅니다. 시계가 초 단위로 돌 때 uint32는 136년 이상을 표현하기 때문입니다. 그래서 시점 저장에는 uint48, 기간 저장에는 uint32를 권장합니다. 이 권장은 타임락 지연, 투표 기간, 베스팅 기간 같은 합리적인 범위의 기간에, 그리고 타임스탬프나 간격이 1초보다 긴 블록 번호로 동작할 때 적용됩니다.

기대 속성과 제안 상태

원문이 명시하는 기대 속성(Expected properties)은 clock() 함수가 감소하지 않아야 한다(MUST)는 것 하나입니다. 보안 고려사항 절에는 알려진 보안 문제가 없다고만 적혀 있습니다. 한편 이 문서의 상태는 검토(Review)입니다. 아직 최종 확정되지 않은 제안이므로 인터페이스나 요구사항이 앞으로 바뀔 수 있다는 점을 구현 전에 확인하는 것이 좋습니다.

ERC 원문 · ← ERCs