NIGO도 하나의 자산으로: Direct와 프로그램 실행을 함께 둔 이유
A가 가진 자산 100 중 20을 B에게 보내려고 한다. A가 직접 보낼 수도 있고, 다른 사람에게 일정 한도 안에서 대신 사용할 권한을 줄 수도 있다. 결과가 A의 80과 B의 20으로 같더라도, 원장이 확인해야 할 근거는 다르다. 앞에서는 A의 소유권을, 뒤에서는 사용자의 권한과 남은 한도를 확인해야 한다.
그렇다면 두 일을 지원하는 자산은 모든 전송에서 프로그램을 실행해야 할까? 또 네트워크의 기본 통화인 NIGO는 다른 자산과 별도의 구조로 남겨야 할까?
nigo-protocol은 9월 27일 재설계에서 NIGO도 공통 Native Asset 모델의 하나로 다루면서, 소유자에게 허용된 Direct Cell 전송을 유지하는 방향을 정했다. 공통화하려는 것은 자산을 식별하고 권한과 수량 변화를 검증하는 방법이다. 이 글은 10월 19일 기준 구현을 바탕으로, 같은 자산에 직접 전송과 프로그램 검증을 함께 둔 이유를 돌아본다.
내 자산 20을 보내는 데 필요한 것
설명용 자산 X를 하나 두자. X는 소유자의 직접 전송을 허용하고 현재 전송 가능한 상태다.
이를 구현에서는 각각 OWNER_DIRECT와 ACTIVE로 표시한다.
A에게 X 100, B에게 0이 있으며, 전체 공급량도 100이라고 가정한다.
이 글의 숫자는 원리를 설명하기 위한 예제다. 수수료에 쓰는 NIGO는 X의 수량과 별도로 계산한다.
Direct Cell 거래에는 소비할 기록과 새로 만들 기록을 담는다. A는 자신의 X 100이 담긴 셀을 소비하고, A의 80과 B의 20을 담은 셀을 만들겠다고 서명한다. 원장은 해당 입력이 유효한지, A가 사용할 권한이 있는지, X의 현재 전송 규칙을 지키는지 검사한다. 입력 100과 출력 80+20도 일치해야 한다.
이때 X의 정책 프로그램을 실행하지 않는다. 전송 허용 여부가 이미 원장의 명시적인 규칙에 있고, 이 요청에는 다른 사람의 사용 한도나 상품별 업무 조건을 해석할 일이 없기 때문이다. 성공하면 A=80, B=20, 공급량=100이 된다.
Direct Cell의 거래 준비를 다룬 글에서는 이처럼 결과를 명시한 요청을 원장 밖에서 작성하고 서명하는 가능성을 설명했다. 그 구조를 유지하려면 프로그램이 있는 자산이라는 이유만으로 모든 전송에 프로그램 실행을 요구할 필요가 있는지부터 따져야 했다.
프로그램으로 통합하면서 다시 본 선택
업무 규칙을 Native Program으로 옮기던 중간 구현에서는 사용자 발행 자산의 Direct 전송을 일괄 제한했다. 자산마다 다른 승인 조건을 실행 엔진의 개별 분기로 처리하지 않고, 정책 프로그램이 맡도록 정리하는 과정이었다. NIGO의 일반 전송은 별도 경로로 남았다.
이 선택은 프로그램이 자산의 규칙을 책임진다는 점을 분명하게 만들었다. 하지만 두 가지 질문이 남았다. 별도의 업무 조건이 없는 소유자 전송까지 매번 정책 코드를 실행해야 할까? NIGO의 잔액과 위임 사용은 왜 다른 자산과 다른 틀에서 관리해야 할까?
가령 X가 사용 한도 기능을 제공하더라도 A가 자기 자산을 보내는 거래에는 그 한도를 사용하지 않는다. 자산에 프로그램이 연결되어 있다는 사실과, 지금 발생하는 효과에 프로그램의 승인이 필요하다는 사실을 구분할 수 있다.
그래서 자산을 공통 모델로 묶고, 효과마다 필요한 승인 근거를 적용하는 구조를 선택했다. 소유자의 직접 이전은 명시적인 전송 규칙으로 검사하고, 위임 사용이나 공급 변경은 해당 정책의 검증을 거친다. 실행 엔진이 정책 코드를 읽고 “간단해 보이는 전송”을 자동으로 골라내는 방식은 아니다.
같은 20을 보내도 승인의 의미는 다르다
이번에는 같은 초기 상태에서 A가 사용자 S에게 X를 30까지 사용할 수 있도록 승인했다고 하자. S는 A와 다른 주소이며, 정책이 실제 호출 주체로 확인하는 사용자다. 정책 프로그램 자체에 30을 주는 것이 아니다.
승인이 확정된 직후에도 잔액은 A=100, B=0이다. 승인 30은 자산을 옮겨 놓은 잔액이 아니라, S가 A의 자산을 사용할 수 있는 한도다. 이후 S가 X 20을 B에게 보내면 정책은 S의 신원과 남은 한도를 확인한다. 자산 이전과 한도 감소가 함께 승인되어야 A=80, B=20, 남은 한도=10이 된다.
아래 세 장면은 이어지는 거래 목록이 아니다. 각각 A=100, B=0에서 출발하는 별도 경우이며, 위임 장면에서는 표에 적힌 승인이 사용 요청보다 먼저 확정되어 있다고 가정한다.
| 장면 | 필요한 근거 | 거래 뒤 X 상태 |
|---|---|---|
| A가 직접 20 전송 | 소유권·현재 Direct 허용·수량 보존 | A80, B20, 공급100 |
| 승인 30을 가진 S가 20 사용 | 정책이 확인한 S의 권한과 한도 | A80, B20, 한도10, 공급100 |
| 승인 10을 가진 S가 20 요청 | 한도 부족으로 정책이 거절 | A100, B0, 한도10, 공급100 |
마지막 경우에는 이미 확정된 승인 10이 그대로 남는다. S가 정책 검증에 실패했다고 A의 소유자 전송 경로를 대신 쓸 수는 없다. Direct는 A의 자산을 S가 가져갈 권한을 만들어 주지 않는다.
현재 표준 정책은 위임 사용과 발행 같은 기능을 여러 모듈로 조합한다. 이 구현의 세부 구성이 바뀌어도 핵심 구분은 같다. 원장이 공통으로 검사할 조건과, 정책이 해석해야 할 업무 조건을 나누어 둔다.
NIGO도 같은 모델에 넣는 이유
NIGO가 별도 구조에 남으면 같은 원장 안에서 “누구의 어떤 자산이 얼마인가”를 찾는 방법부터 갈라진다. 위임 권한을 어디에 기록하고, 어떤 근거로 잔액을 바꾸며, 변화를 어떻게 설명하는지도 각각 맞춰야 한다. NIGO를 쓸 수 있는 프로그램 몇 개를 추가하는 것만으로는 이 중복이 사라지지 않는다.
현재 모델에서는 NIGO에도 공통 자산 식별자와 통제 정보, 잔액 셀, 자산에 연결된 정책이 있다. 자산 목록에서도 같은 기준으로 발견하고, 잔액을 변경할 때도 효과와 승인 근거를 함께 검사한다. NIGO의 위임 사용 기록 역시 NIGO 자산의 정책 상태로 다룬다.
다만 NIGO는 체인 초기 상태에서 정한 고정 식별자와 기본 통화의 역할을 유지한다. 일반 소유자 전송은 공통 Direct 규칙을 따르고, 수수료 정산이나 EVM의 통화 이전은 해당 실행 문맥에서 인증된 프로토콜 근거를 따른다.
이 그림은 승인 근거가 모이는 관계를 나타낸다. 모든 자산이 세 권한을 모두 갖는다는 뜻은 아니다. NIGO를 공통 모델에 넣어도 일반 정책이 NIGO를 임의로 발행하거나 소각할 수는 없다. 현재 NIGO의 위임 사용은 Native 경로에서 지원하며, 이를 EVM에도 개방한 것으로 해석해서는 안 된다.
앞의 X 예제와 달리 NIGO 자체를 보낼 때 수수료가 있으면, 보내는 양과 실제 수수료를 같은 NIGO 수지 안에서 함께 계산해야 한다. 공통 모델은 이런 통화 역할과 개별 정책의 권한을 구별한 채 검증할 수 있는 기반이다.
Direct도 현재 자산 규칙을 확인한다
소유자의 서명이 있다고 언제나 Direct가 허용되는 것은 아니다.
예를 들어 별도 자산 Y가 매 전송에 정책 검증을 요구하는 POLICY_REQUIRED라면,
A가 Y 100을 가지고 서명했어도 Direct로 20을 보내는 요청은 거절된다.
Y의 잔액은 A=100, B=0으로 남으며, 전송하려면 Y의 정책이 요구하는 조건을 충족해야 한다.
Direct가 가능한 X에서도 거래가 참조한 자산 통제 정보와 정책 연결 정보가 현재 값과 맞아야 한다. 거래를 준비한 뒤 관련 정보가 바뀌었다면 예전 조건으로 확정하지 않는다. 필요한 정보가 누락되거나 해석되지 않는 경우에도 전송을 허용하지 않는다.
반대로 명시적인 Direct 허용과 유효한 자산 정보가 유지된다면, 소유자 이전의 검증을 위해 정책 프로그램을 실행하거나 그 실행 가능 여부를 확인할 필요는 없다. 이 구분 덕분에 정책 기능의 실행 상태와 기본 소유자 전송을 서로 다른 조건으로 다룰 수 있다. 현재 구현에는 NIGO와 사용자 발행 자산의 이런 전송, 오래된 참조와 잘못된 통제 정보의 거절을 확인하는 회귀 검증이 있다.
공통 자산이 서로 다른 실행을 만날 때
세 가지 거래 실행 방식은 변경안을 직접 제출하거나, 프로그램으로 검증하거나, EVM 코드를 실행하는 요청의 차이를 다뤘다. 이번 재설계는 그 아래에 있는 자산을 다시 정리한 작업이다. NIGO를 포함한 공통 자산 위에서 소유자 전송, 위임 사용, 통화 효과가 각각 필요한 근거를 갖도록 했다.
다음으로 볼 장면은 A가 Native 거래로 사용 권한을 승인하고, EVM의 업무 계약이 그 권한으로 같은 자산을 쓰는 경우다. 실행 방식이 바뀌어도 잔액과 승인을 이어서 사용할 수 있어야 하나의 원장이라는 선택이 의미를 갖는다. 그리고 그 업무가 도중에 실패했다면, 자산 이전과 승인 한도는 어디까지 함께 되돌아가야 할까?