ERC-5485 관할권·인가·집행 선언 인터페이스 (Jurisdiction, Accreditation, and Enforcement)

Review · 기타 · 2022-08-17 작성

스마트 컨트랙트가 자신이 따르는 관할권, 그 관할권에서 받은 인가, 그리고 집행 결정을 전달받는 통로를 표준 방식으로 선언하고 조회할 수 있게 하는 인터페이스입니다.

왜 필요한가

스마트 컨트랙트는 네트워크 합의로 실행되는 디지털 계약이지만 현실의 법과 제도를 닮은 영역으로 쓰임이 넓어지면서 빠진 조각이 드러났습니다. 어떤 컨트랙트가 어느 법체계(관할권, jurisdiction)를 따르는지, 그 체계의 권위자가 이 컨트랙트를 정식 참여자로 인정(인가, accreditation)했는지, 권위자의 결정을 컨트랙트에 어떻게 전달하는지를 온체인에서 구조적으로 표현할 방법이 없었습니다. 스테이블코인은 준비금 보관과 상환, 동결, 규제 준수가 특정 법적 권위에 달려 있고, 토큰화 주식은 증권법과 양도 제한, 투자자 권리가 법적 관할에 따라 완전히 달라집니다. 반대로 어떤 컨트랙트는 외부 체계를 전혀 따르지 않는 자기주권(self-sovereign) 상태임을 분명히 하고 싶어 합니다. 두 상태를 모두 표준으로 표현할 수 없으면 컨트랙트끼리 관할권 호환성을 확인하거나 상대가 인가받은 참여자인지 검증하는 일이 제각각이 되고 분쟁이 생겼을 때 어떤 절차를 따라야 하는지도 자동으로 판별할 수 없습니다.

구현해야 하는 것

심층 설명

주권, 관할권, 인가, 집행 네 가지 개념

원문은 네 가지 기초 개념을 표준화합니다. 주권(sovereignty)은 컨트랙트가 자기주권적인지 아니면 상위 체계에 속한다고 주장하는지, 관할권(jurisdiction)은 어떤 외부 권위를 따르기로 선택했는지, 인가(accreditation)는 그 권위가 컨트랙트를 체계 안의 유효한 참여자로 공식 인정했는지, 집행(enforcement)은 권위가 내린 결정과 판정을 컨트랙트에 전달하고 확인받는 방법입니다. 원문은 국가가 법인을 설립 인가하거나 학교가 동아리를 승인하듯 인가를 받아야 행동 가능한 참여자가 되는 경우와, 독립 선언처럼 외부 관할이 없음을 명시하는 경우를 모두 들며 종속과 자기주권 두 방식을 함께 표현하는 것이 제도적 관계를 온체인에서 정확히 모델링하는 데 필수라고 설명합니다.

sourceOfAccreditation()의 규칙

이 컨트랙트를 어떤 관할권이나 거버넌스 체계의 유효한 참여자로 인가한 주소를 반환합니다. 인가 기관이 존재하면 그 주소를 반환해야 하고(MUST), 외부 인가를 인정하지 않는 자기주권 동작이라면 address(0)을 반환해야 합니다(MUST). 반환값은 컨트랙트 수명 동안 안정적으로 유지되거나, 정해진 거버넌스 또는 업그레이드 절차를 통해서만 바뀌어야 합니다(SHOULD). 인가는 권위자만 줄 수 있는 것이므로, 이 함수의 값은 컨트랙트 스스로의 주장이 아니라 외부 승인 관계를 나타냅니다.

jurisdiction()의 규칙

이 컨트랙트가 규칙을 따르겠다고 주장하는 주된 관할권 또는 체계를 반환합니다. 하나의 컨트랙트가 관할과 인가 두 역할을 모두 수행한다면 sourceOfAccreditation()과 같은 주소를 반환할 수 있습니다(MAY). 외부 관할권을 주장하지 않으면 address(0)을 반환해야 합니다(MUST). 이 값은 인가 여부와 무관하게 컨트랙트가 스스로 어느 상위 체계에 정렬하는지를 나타냅니다. 즉 관할권만 선언하고 인가는 아직 받지 못한 상태도 표현할 수 있습니다.

imposeEnforcement()의 처리 방식

집행 제안을 컨트랙트에 제출하는 표준 진입점입니다. 구현은 이 함수의 접근 제어를 반드시 정의하고 문서화해야 합니다(MUST). 예로 jurisdiction(), sourceOfAccreditation(), 또는 선별된 권위자 목록으로 제한할 수 있습니다. 구현은 제안된 동작의 일부나 전부를 즉시 실행하거나, 나중에 심의하도록 기록하거나, 정책에 따라 부분 수용 또는 완전히 무시할 수 있습니다(MAY). 집행 시도가 있었다는 사실을 온체인에서 검증할 수 있도록 이벤트를 내보내거나 상태를 저장하는 것이 권장됩니다(SHOULD). 함수가 payable인 이유는 실행 항목이 0이 아닌 value를 지정하거나 처리 수수료가 필요할 때 ETH를 함께 보낼 수 있게 하기 위해서입니다.

ERC-5247 기반 데이터 구조

집행 제안은 ERC-5247을 확장한 두 구조체로 표현합니다. IERC5247Executable은 하나의 실행 가능한 동작으로, 호출 대상 주소 target, 함께 보낼 ETH 양 value(wei 단위), 가스 한도 gasLimit, 호출 데이터 data 네 필드를 가집니다. 실행에 대한 보장은 없으며 구현이 이 필드들을 무시하거나 다르게 해석할 수 있습니다. gasLimit도 구현이 무시할 수 있다고 명시되어 있습니다. IERC5247Executables는 이런 동작들을 순서 있는 목록으로 묶은 하나의 집행 제안입니다.

관할권과 인가를 분리한 이유

두 개념은 근본적으로 다른 관계를 나타내기 때문에 분리했습니다. 관할권은 자발적입니다. 컨트랙트가 일방적으로 어떤 체계의 규칙을 따르겠다고 선언할 수 있습니다. 반면 인가는 외부 승인이 필요합니다. 권위자만이 컨트랙트를 자기 체계의 수용된 참여자로 공식 인정할 수 있습니다. 관할권은 정렬을, 인가는 수용을 표현하며 관할권을 선언했다고 해서 권위자가 그 컨트랙트를 인정한다는 뜻은 아닙니다. 또한 권위자는 보통 자신이 인가한 컨트랙트에만 집행을 내리므로, 집행 경로를 만드는 것은 인가입니다. 이 구분은 현실 제도의 작동 방식을 반영합니다. 체계의 규칙을 따르는 것은 자기 선언이지만 그 안에서 공식 지위를 얻으려면 권위자의 명시적 행동이 필요합니다.

하위 호환성

관할권과 인가가 없는 상태는 기존 동작의 상위 집합이므로 기존 컨트랙트와 호환됩니다. 이 인터페이스를 구현하지 않은 컨트랙트는 기본적으로 어떤 관할권도 따르지 않고 인가도 없는 자기주권 상태로 간주됩니다. 또한 집행 제안의 기반으로 ERC-5247을 쓰기 때문에, DAO 금고 같은 멀티시그(Multi-Sig) 지갑을 비롯해 이미 ERC-5247을 구현한 컨트랙트와도 호환됩니다.

아직 검토 중인 제안입니다

이 ERC의 상태는 Review입니다. 커뮤니티 검토를 받는 단계이므로 인터페이스와 규칙이 최종 확정 전에 바뀔 수 있습니다. 실제 구현을 계획한다면 원문의 변경 여부를 계속 확인하는 것이 안전합니다.

쓸 때 주의할 점

ERC 원문 · ← ERCs